Trust, but Verify. Then Delegate.

Reflections from Cyber Defense Summit 2026 on agentic AI, familiar security principles and what we have learned applying them to our own work.

This was my third Cyber Defense Summit, including its earlier mWISE days. I keep returning because of the conversations. It's a relatively small gathering of practitioners, and the discussions often stay with me longer than the presentations.

This year, one presentation struck a chord for a reason I did not expect. Royal Hansen's keynote, “AI is here. What’s our next move?”, introduced a more detailed way to look at how teams mature in their use of AI agents. As he walked through it, I kept thinking about what we've been doing inside Foresite.

My work at Foresite spans much of the commercial lifecycle: go-to-market strategy, sales execution, revenue operations, partner development and the systems connecting them. That's given us a practical place to experiment with agents across account intelligence, lead qualification, CRM data quality, partner coordination and campaign execution. Some provide context or prepare recommendations; others work across multiple systems, with decisions and approvals still firmly in human hands.

We weren't consciously working from Hansen's ladder. But the progression he described, and the questions it raises at each stage, felt familiar. We had been working through much the same issues, often by applying security principles most of us in cybersecurity have known for years.

A useful way to think about agent maturity

What I appreciated about Hansen's framework was its breadth. It wasn't simply a distinction between an AI assistant and a fully autonomous agent. The seven levels describe increasingly independent working relationships, from providing context to carrying out defined assignments, initiating work and ultimately owning an ongoing objective.

That distinction matters for any team looking to automate work. A workflow that prepares something for review is different from one that can take action, and different again from one that decides when action is needed. The questions change as responsibility expands: what can the agent access, what can it do, how do we know it performed correctly, and who remains accountable?

I found the framework refreshing because it offers more than an ambitious end state. It provides a practical way to examine a use case before expanding its scope. There is no requirement that every workflow reach the top of the ladder. Sometimes a bounded agent with a deliberate human approval step is exactly the right design.

The level names below are from the framework Hansen presented. The working descriptions and review questions are my application to business workflows. They are not an official Google assessment, and the considerations build on one another.

Each level carries every review question below it. The newer scale also separates completing an assignment, deciding when work begins, and managing an ongoing objective, which the earlier scale grouped as “Fully Agentic / Autonomous.” Level names from Royal Hansen’s Cyber Defense Summit 2026 keynote.

We had been following a similar path without naming it

As I listened, I recognized the sequence we've taken with our own use cases. We started with relatively modest agents: research, preparation and other tasks where we could inspect the output before allowing anything to change. We tested whether the work was actually useful, corrected what failed and gradually expanded the assignments we were willing to delegate.

Over time, methods that worked became reusable skills, and those skills became shared plugins and connected workflows. What started with discrete tasks expanded into processes spanning research, lead management, partner intake, campaign operations and reporting. We progressed incrementally, learning where automation improved consistency and where it introduced a new dependency or needed a clearer decision boundary.

The lessons became more practical as workflows crossed teams and systems. Something that ran well for its creator failed for a teammate with different permissions. Older versions of skills continued to circulate after we improved the shared copy. The challenge was no longer just whether an agent could complete a task; it was whether we could make that work dependable, governed and repeatable for other people.

One example is our field marketing plugin, which now begins with a read-only pre-flight check of its connected systems. If access is missing, it identifies the issue before the operator is halfway through the work. In lead triage, the workflow can prepare research and recommend a disposition, but a person still makes the final qualification decision. Different processes, but the same discipline: know the environment, constrain the action and make responsibility explicit.

The agent prepares; a person commits. An instruction to ask before acting is not an enforced permission boundary: authorization belongs in the infrastructure around the agent.

None of that is especially novel from a cybersecurity perspective. But hearing Hansen articulate the maturity levels gave those choices a clearer structure. It validated the direction we had taken while making it easier to ask what we should prove before moving a workflow further.

The security fundamentals were there all along

In cybersecurity, we hear terms such as least privilege, zero trust and secure by design so often that they can become shorthand. Applying agents to revenue systems and cross-functional work made their purpose hard to ignore. Before software is allowed to act, we still need to ask the question we'd ask of any workload: what does this assignment actually require?

A workflow that prepares a partner registration doesn't also need permission to submit it. An agent researching CRM records shouldn't inherit the ability to rewrite them simply because its creator can. That's least privilege, but it's also separation of duties. Preparing a recommendation and authorizing its execution need not belong to the same actor.

Identity is another place where the old principles matter. When an agent works through an employee's credentials in a harness, the receiving system may log its changes as though the employee made them directly. For work performed under an agent's own authority, a distinct, narrowly scoped non-human identity—a workload or agent identity, or a dedicated service account where appropriate—can make action attribution clearer. When an agent acts on behalf of a user, we should still be able to trace both: which agent took the action and whose authority it used.

But identifying the actor is only part of the picture. We also need enough of an audit trail to reconstruct the tools invoked, the records affected, the approvals given and the outcome. The distinction between agent action attribution and broader observability is important: knowing what identity made a change is not the same as knowing how the workflow arrived there.

And a prompt saying "ask before acting" isn't a substitute for a permission boundary. Under zero trust, authorization has to be checked where the action occurs. That's also the secure-by-design argument: build appropriate controls into the workflow from the beginning, rather than adding them after people start depending on it. Google's Secure AI Framework makes a similar distinction between agent permissions, user control and observability.

Connecting agents to more systems can also widen the blast radius of an error. An incorrect record can affect seller routing, partner coordination, pipeline attribution or a customer-facing communication. Defense in depth becomes practical here: narrow permissions, enforced approval points, monitoring and a way to interrupt or reverse unwanted actions where feasible. These aren't new security concepts. What's changing is the speed and reach of the software to which we're applying them.

What it takes to give an agent more responsibility

Hansen's discussion also made me think about maturity beyond the individual agent. As we share skills and connect workflows, the system surrounding an agent becomes as important as the agent itself. Version control, tool permissions, input quality, approval paths and auditability all affect whether the result can be trusted.

The next test is whether a workflow remains dependable when someone else runs it, the inputs change or an integration behaves differently than expected. A successful demonstration is a starting point. Operating it responsibly calls for repeatable evaluation, clear ownership and a feedback loop that improves the shared workflow rather than just one person's copy.

We can evaluate progress in ordinary terms: how often a workflow produces a correct result, which exceptions recur, whether its actions can be reconstructed and whether someone can intervene when things go wrong. Improving those measures may justify a wider assignment. It does not automatically justify broader access.

That is an important distinction for security teams and for every other function deploying agents. The right degree of autonomy depends on the task and the consequences of getting it wrong, not on a desire to claim we've reached a particular maturity level.

Questions worth asking before expanding an agent's role

The ladder gives us a useful way to examine each new use case. These are the questions I would bring to the discussion:

1. What responsibility are we actually delegating, and does the agent need to initiate actions on its own?
2. Which systems and information does it need, and are its permissions limited to that work?
3. What changes can it make, and which boundaries are enforced by tools or workflow controls rather than instructions?
4. What evidence tells us it works reliably across different users, inputs and conditions?
5. Who can review, stop or reverse its actions, and how do lessons from failures reach everyone using the workflow?

These questions apply to revenue operations, partner workflows and business development just as they do to an agent working in a SOC. The stakes may differ, but the responsibility to understand and govern the system does not. They also connect to our broader work on shadow agent risk and the importance of evaluating agents before extending trust.

I left the summit with a better way to describe something we've been learning through experience. Agentic AI may be new territory for many business teams, but the discipline needed to deploy it well is not. Hansen's framework helps put that discipline into a sequence that teams can understand, question and use.

For us, that means continuing to experiment, measuring what works and being deliberate about what we allow an agent to do next. It's a useful standard to apply to our own operations before asking customers to place the same trust in us.

See how we apply this discipline in the SOC, where named practitioners approve every high-impact action. Book an Agentic SOC workshop →