Projects / 01
Agent Security Control Plane
Prototype control plane for governing how agents reach memory, tools, identities and data, with policy and telemetry as first-class layers.
Overview
We investigate what a unified security layer for agentic systems would need to look like. As soon as an organisation runs more than a handful of agents, the security-relevant decisions stop being about a single model call and start being about relationships: which agent is acting, on whose behalf, against which tool, using which memory, under which policy, and with what record left behind.
Those relationships are currently governed by whatever each framework happens to expose. Permissions live in tool definitions, identity is implicit in an API key, memory is an unlabelled vector store, and the audit trail is application logging. The prototype asks whether these concerns can be lifted out of individual agents and expressed once, in a layer that sits above them.
The work is deliberately scoped as a design study. We are more interested in whether the abstractions hold — agent inventory, agent identity, memory provenance, runtime policy, human approval — than in shipping an implementation of them.
The problem
Agentic deployments accumulate ungoverned surface faster than they accumulate controls. New agents are created by teams rather than by a platform, tool servers are added because they are convenient, and memory grows through ordinary operation rather than through an authoring process. Nobody holds a complete list of any of these.
The consequence is that ordinary security questions become unanswerable. Which agents can reach production data? Which tools can take an irreversible action without a human in the loop? Where did the memory that shaped this decision come from, and who wrote it? An organisation that cannot answer these cannot reason about blast radius.
Existing controls are also placed badly. Identity and access management assumes human or service principals with stable intent, not a non-deterministic process that composes its own plan at runtime. Application-layer guardrails sit inside the very component they are meant to constrain. A control plane is an attempt to place enforcement somewhere an agent cannot reach.
Architecture
The architecture separates four horizontal layers. A control plane sits above the agents. The agents sit above the resources they need — data stores, tool servers, memory. Enterprise systems sit below that. Observability runs vertically through all of it and terminates in the SOC.
The control plane holds the state that individual agents must not be trusted to hold about themselves: what exists, what it is allowed to do, and what it has done. Enforcement points sit on the paths between an agent and anything outside it, so that a compromised or misled agent still has to cross a boundary it does not control.
- Agent inventory and identity
- An authoritative register of agents, each bound to a distinct identity rather than sharing a service credential, so that actions attribute to a specific agent and not to the platform.
- MCP server and tool inventory
- A register of tool servers and the individual tools they expose, tracked as they change, so that new capability appearing in an agent's reach is a visible event rather than a silent one.
- Tool permissions
- Per-agent capability grants evaluated at call time, distinguishing read from write and reversible from irreversible actions.
- Memory provenance and security
- Metadata carried with every memory record describing its origin, the identity that wrote it and its trust level, evaluated on recall rather than only on write.
- Runtime policy and human approval
- Policies evaluated during execution, with defined conditions under which an action is suspended and routed to a person instead of being completed autonomously.
- Behaviour analytics and telemetry
- Structured records of agent activity, retained as an audit trail and exported to observability and SIEM pipelines for correlation with the rest of the estate.
Telemetry is not an afterthought in this design. If the control plane is the only component with a complete view of agent activity, then it is also the only component that can produce a usable audit trail, and that trail is what makes the rest of the security programme able to reason about agents at all.
Security model
The model treats the agent as untrusted. Not malicious by construction, but capable of being steered — through prompt content, tool output, retrieved documents or poisoned memory — into actions its operator did not intend. Any control that lives inside the agent's own reasoning can be argued away by the same input that caused the problem.
- Trusted
- The control plane itself, its policy store and its audit log. These are assumed to run outside the agent's influence and to be administered through ordinary infrastructure controls.
- Untrusted
- Agent reasoning, model output, tool responses, retrieved documents and memory content. All are treated as attacker-influenceable data.
- Partially trusted
- Tool servers and enterprise systems. They are assumed to enforce their own access controls correctly, which is why the control plane binds each agent to a distinct identity rather than relying on a shared one.
The threats in scope are privilege accumulation across agents, tool misuse, memory-mediated influence and loss of attribution. The threats explicitly out of scope are compromise of the underlying host, of the model weights, or of the control plane's own administrative access — if any of those fall, the control plane offers nothing.
Current status
The project is at prototype maturity. The layered design and the inventory, identity and policy abstractions have been worked through in enough detail to be tested against concrete scenarios in the lab. They have not been validated under production load, adversarial testing by third parties, or the operational pressure of a real estate.
Work to date is design and partial implementation, not a released system. There are no deployments outside our own lab environment and no external users.
Limitations
One limitation is coverage. The design assumes agents reach the outside world through paths the control plane mediates. Any direct network egress, embedded SDK call or side channel bypasses it entirely, and in real deployments those paths are common.
A second limitation is that runtime policy evaluation adds latency to every mediated action, and we have not characterised that cost. A control plane that makes agents noticeably slower will be routed around by the teams operating them.
A third is that behaviour analytics for agents is largely unsolved. We can record what an agent did; deciding whether that behaviour was anomalous requires a baseline of normal that is unstable, because agent behaviour changes whenever a prompt, a model or a tool changes.
Finally, the human approval path is the weakest part of the design. Approval fatigue is a well-understood failure mode, and we do not yet have a principled way to decide which actions genuinely warrant a person.
Roadmap
- Define a minimal enforcement point interface and implement it for a single tool protocol end to end.
- Measure the latency cost of runtime policy evaluation on mediated tool calls in the lab.
- Model bypass paths explicitly and document which are detectable and which are not.
- Connect memory provenance metadata to recall-time policy decisions, linking this work to the memory contract specification.
- Export a stable telemetry schema and test correlation against the SOC lab's pipeline.
- Publish the trust model and threat scope for external critique before extending the implementation.
Detail
Topics
- agent security
- control plane
- policy enforcement
- agent identity
- MCP
- observability
- SIEM