Agent Security: Identity, Tools, Memory and Runtime Policy

A great deal of AI security attention is directed at the model: what it will say, what it can be made to say, and how robustly it refuses. That work matters, but it addresses a shrinking share of the risk in a deployed agentic system. An agent with tool access, a credential, and persistent memory can cause consequences that have very little to do with the text it produces. The security surface has moved from the model to the runtime around it.

This programme investigates that runtime. We treat an agent not as a model with a prompt but as a distributed system component with an identity, a set of permissions, a dependency graph, mutable state, and an execution path — and we ask which of the controls that apply to any such component are currently missing.

Agent identity and authorisation

The most common shortcut in current deployments is to run the agent as the user. The agent inherits the user's token, the user's roles, and the user's blast radius. This is convenient and it is wrong, for a reason that is structural rather than incidental: an agent acting on behalf of a user is not the same principal as the user.

The differences are practical. The agent acts at machine speed and volume. It acts when the user is not present. It acts on inputs the user has never seen, some of them attacker-influenced. It has no independent judgement about whether a request is reasonable. Collapsing these two principals into one identity means that every audit trail attributes the agent's actions to a person who may not have been aware of them, and every authorisation decision is made against permissions that were scoped for human working patterns.

We investigate what a first-class agent identity requires: a distinct principal, delegation that is explicit and bounded rather than inherited wholesale, permissions scoped to the operations the agent actually performs, credentials with lifetimes matched to a task rather than a session, and audit records that name both the agent and the human on whose behalf it acted.

Tools and permissions

An agent's capability is the union of its tools. That makes the tool set the most direct expression of what an agent can do, and yet in most deployments there is no maintained inventory of it. Tools are registered in code, added by developers, and expanded incrementally, with no equivalent of the review that a new integration or a new IAM policy would attract.

• Inventory: which tools exist, which agents can reach them, and who added them.
• Classification: which tools read, which mutate state, and which perform actions that cannot be undone.
• Permission granularity: whether a tool exposes a narrow operation or a general-purpose capability with a narrow name.
• Argument-level policy: whether the constraint applies to calling the tool at all, or to calling it with particular arguments against particular resources.
• Composition: what an agent can achieve by chaining several individually low-risk tools.

The last of these is the least well handled. Risk assessment of tools is usually performed tool by tool, while agents operate by composition. A tool that reads a file and a tool that posts to an external endpoint are each defensible in isolation.

MCP servers and the AI supply chain

The Model Context Protocol has made it straightforward to give an agent access to external capability, which means it has also made it straightforward to extend an organisation's trust boundary without noticing. An MCP server is a dependency in the strong sense: it supplies tool definitions, it returns content that enters the agent's context, and it frequently holds credentials of its own.

We approach this as a supply chain problem, because the questions are the ones supply chain security already asks. What servers are connected, and who approved them? What is the provenance of the server implementation and how is it updated? What can a server's tool descriptions cause the agent to do, given that those descriptions are themselves content the model reads? What credentials does the server hold, and what is the consequence if it is compromised or if its behaviour changes between versions? An agent that trusts a server's tool descriptions and its returned content is, in effect, running code and reading data from a third party at the point of decision.

Memory as part of the runtime

Persistent memory belongs in this programme rather than beside it, because memory is where the other three surfaces meet. Content arrives via tools, is written under an agent identity, and later influences a privileged action. Our work on memory poisoning and on runtime memory contracts is treated as a branch of this programme, and the same principle applies: the security decision belongs at the point where stored content is about to influence an action.

Runtime policy enforcement

Guardrails expressed in a system prompt are guidance, not enforcement. They are evaluated by the same component an attacker is attempting to influence, which makes them a defence with no independent standing. We investigate policy enforced outside the model, in the path between the agent's decision and the effect of that decision.

A useful enforcement point sees the agent identity, the tool and its arguments, the resource being acted on, the provenance of the context that led to the call, and the state of the session. From those it can allow, deny, constrain arguments, require additional evidence, or escalate to a human. The engineering difficulty is not the decision logic; it is that the enforcement point must sit somewhere the agent cannot route around, and many current architectures have no such place.

Telemetry across agent, tool and memory

Detection and investigation both depend on being able to reconstruct why an agent did something. That requires telemetry joined across three layers that are usually instrumented separately, if at all: the agent layer (sessions, reasoning steps, delegations between agents), the tool layer (calls, arguments, results, errors, and which server served them), and the memory layer (writes, recalls, mutations, expiries, and provenance).

A common identifier spanning the three is what turns a set of disconnected logs into an investigable trail. Without it, an analyst can see that an action occurred but cannot establish what led to it — which is the difference between an alert and an investigation.

The autonomy question

Underneath the individual controls sits a design question that the controls exist to serve. Autonomy is not a single setting for an agent; it is a property of each operation the agent performs. The same agent may reasonably read a document without supervision, propose a configuration change for review, and require explicit approval before sending an external communication.

We take this to be the question the rest of the programme is instrumental to. Identity determines who is acting, tool policy determines what the action can be, memory governance determines what the action is based on, and telemetry determines whether anyone can tell afterwards. All four exist so that autonomy can be granted deliberately and per operation, rather than granted wholesale by default and reconsidered after an incident.