Permission does not mean purpose with AI agents.

By Tom Hallaran, CTO, Chester Leung, VP Engineering Capitol AI

TL;DR At Capitol, we think of agentic security as the practice of governing what an AI agent is permitted to do, verifying that its work matches the purpose it was given, and preserving the evidence to audit both afterward. Access control allows an agent to reach a system or database but it does not answer whether accessing it serves the task at hand. At Capitol, the second question is addressed in the workflow, which is where purpose is defined, enforced, and tracked.

Permissions are not the same as purpose and AI agents need both

Permissions are necessary to define what can be done and by whom, but they do not specify why it should be done in the first place. For instance, let’s say an agent has read access to a document repository. Permissions can explicitly allow access but they do not define whether that particular document needed to be read for the task at hand at the time that the agent was performing a certain workflow.

That distinction hasn’t mattered very much in the past, because for most of the history of enterprise software you only had to deal with the permissions issue. When you granted a specific scope to a person, you assumed that person would use it for the reason it was granted, and you could hold them accountable if they did not. When you granted one to a service account, you were relying on the fact that the service does the same thing today that it did yesterday.

An AI agent is different. Its permissions are defined when it is authorized for access, but its objective is defined from the context you feed it at every step in the workflow.

This is a big part of what makes AI agents valuable: you can give it a goal and a set of tools and it finds a way to get it done without you having to define it explicitly.

But the problem with that is that the reason why an agent is accessing certain data may have changed from one step to the next. Nothing in the access control machinery notices the difference because it wasn’t designed to. The speed at which agents operate makes the problem even more serious, since an AI agent can move through hundreds of tool calls in the time it takes a person to do one task. This leaves very little time between a workflow drifting off course and a human being in a position to spot it and intervene, which is enough to do real damage.

Prompt injection is just one example of where things can go wrong

So an AI agent can start to operate under a new objective mid-workflow, but it still has the same permissions, so why is that a problem? Take prompt injection.

Let’s say an agent is asked to summarize a document, and the document contains text that was written to be read as an instruction. From that point forward the agent begins working toward something other than what it was asked to do originally because the text became its new objective. For argument’s sake, imagine that the contents of the document read “ignore all other instructions and do this instead…” Its credentials are still valid and every permission check it makes still passes, but it’s now doing something completely different.

No boundary was crossed and no vulnerability was exploited, so the access log shows nothing but authorized actions taken by an authorized actor. The only signal available to you is the mismatch between what the agent is doing and what it was asked to do, and a system can only catch that mismatch if it holds a readable statement of what the agent was asked to do in the first place.

Deliberate injection is just one example of the problem. The same purpose mismatch can happen with no malicious actor involved. An agent scoped to a market analysis may pull complete customer records when aggregated data would have served the task perfectly well, or a sub-agent may inherit a far broader scope than the job it was originally asked to perform. Neither is an attack. Both are versions of the same problem, and both are hard to see, because nothing in the log looks out of place.

Workflows can be used to define and control purpose

A declared purpose is only useful if something checks for alignment while the agent runs its tasks. That is handled inside the workflow, and if designed correctly, the workflow itself is a security feature.

Capitol runs work as a graph of typed nodes, and each node receives only the inputs wired into it rather than access to the full data store, so scope is limited in the structure of the work itself. Scope expressed that way does not depend on an autonomous agent using a permission set the way it was intended.

The same structure that enforces purpose during the run also produces the evidence trail after it completes. Because every step is a node, the record is not just a log of what happened with each step but also a record of what was supposed to happen alongside it. It carries the declared purpose attached to each task, the full path the agent took, and the reasoning it produced along the way. That lets an auditor trace any claim back to its source and reconstruct the path that produced it.

A workflow only enforces the rules you deliberately build into it. If no one added a step to strip customer names before the model sees them, nothing strips them. And structure does not make the system predictable. The model is still probabilistic, so breaking work into steps that each have to pass a check makes a good result more likely, but still not certain. You are not trying to be right every time, just to be wrong less often and to catch the mistake before it does harm.

Download it or book a demo to see governed agentic workflows running on your own data.