The Agent Is a Principal, Not a Feature

The Agent Is a Principal, Not a Feature is the reclassification that makes agent security tractable. Once an agent holds credentials and takes actions, it belongs in the same category as a user or a service, and every question you would ask about those becomes askable about it.

Key takeaways

• A principal has four properties: an identity, an authority someone granted, a record of what it did, and a person accountable for it. Most agents have none, having inherited a service account.
• The reclassification is not paperwork. It decides where controls go, and the answer is never inside the model.
• Agents differ from other principals in one way that matters: their instructions arrive at runtime from data they read, which is why OWASP states that fool-proof prevention of prompt injection is not currently apparent.
• Excessive agency has three named root causes, being excessive functionality, excessive permissions and excessive autonomy, and each is fixed in a different place.
• Some teams now have an external deadline. The remainder of the EU AI Act applies from 2 August 2026, except Article 6(1), which shifts evidence from good practice to a requirement.

Read this beside Chapter 2, which draws the boundaries this principal sits inside, and Chapter 5, which gives it an identity. The security-facing companion argument is prompt injection defence in depth.

Somebody asks a simple question in a review: what can this agent do. The honest answer is that it runs as the application's service account, so it can do everything the application can do.

Nobody decided that. It happened by inheritance. The agent was built as a feature inside an existing process, and features inherit the permissions of the process they live in.

Four properties, and most agents have none

A principal, in the ordinary security sense, is an entity that acts. Users are principals, services are principals, and an agent that calls tools with credentials is one too.

Being a principal implies four things. An identity, which is a name that distinguishes it from every other actor. An authority, which is a specific set of permissions someone deliberately granted. A record, which attributes actions to it. And accountability, meaning a person or team who answers for what it does.

Run that list against a typical first agent deployment. It has no identity of its own, because it uses the application's credentials. Its authority is whatever that application had, which was scoped for a different purpose. Its actions appear in logs as the application's actions. And accountability is ambiguous between the team that built it and the team that owns the credentials.

That is not a security posture. It is the absence of one. The absence stays invisible until the first surprising action, at which point it is the whole story.

What is genuinely new, and what is not

Most of agent security is ordinary security applied to a new principal. Least privilege, identity, mediation, isolation, logging: none of that changed.

One thing did. A conventional service takes instructions from code that was reviewed and deployed. An agent takes instructions from text it encounters at runtime, some of which is written by people outside your organisation, and it cannot reliably distinguish that text from your own instructions.

OWASP's 2025 prompt injection entry states the consequence directly: the vulnerability arises from the nature of generative systems, and it is unclear whether fool-proof prevention methods exist. That is the sentence the rest of this book is built on.

So the novel part is not that the agent might be compromised. It is that compromise should be treated as a normal operating condition rather than as an incident, which changes the design rather than the vigilance.

Excessive agency, and where each cause is fixed

OWASP's LLM06 entry names three root causes of excessive agency, and they are useful precisely because each is fixed in a different place.

Excessive functionality means the tools expose more than the task needs, such as an email tool that can send when the feature only summarises. That is fixed in the tool definition, which is Chapter 4.

Excessive permissions means the credentials reach further than required on downstream systems. That is fixed in identity and grants, which is Chapter 5, and enforced at the destination, which is Chapter 6.

Excessive autonomy means high-impact actions execute without independent verification or approval. That is fixed by the approval and containment design, which runs through Chapters 6 and 8.

Their mitigation list is worth reading as an architecture rather than a checklist: minimise extensions, avoid open-ended ones, enforce least privilege, execute in the individual user's context, require human approval for high-impact actions, implement complete mediation via downstream authorisation, and log with rate limits.

The threat model has a new shape

Classical threat modelling assumes an attacker outside the system trying to get in. Agentic systems add a case that does not fit that shape.

The attacker does not need access to your infrastructure. They need to place text where your agent will read it: a support ticket, a web page, a shared document, a code comment, a calendar invitation. The agent then acts with its own legitimate credentials, inside your network, through approved channels.

That is why OWASP's agentic work exists as a separate list. The Top 10 for Agentic Applications was released on 9 December 2025, developed with more than 100 industry experts, researchers and practitioners, and its categories cover goal hijacking, tool misuse, memory poisoning, identity and privilege abuse, inter-agent communication and cascading failure, which are not variations of the application risks that came before.

The practical consequence for a designer is that the question shifts. Not "how do we keep the attacker out", which remains necessary, but "what can this principal do if it is currently following an attacker's instructions", which is answerable and architectural.

The question a review will actually ask

Security reviews for agentic systems converge on one question, and knowing it in advance shapes the design.

The question is: if this agent were following an attacker's instructions right now, what could it do before anything stopped it. Not whether it could be compromised. Assume it is.

Answering requires four facts, and a team that cannot produce them has not finished the design. The complete list of tools it can call. The full reach of its credentials, including anything transitively accessible. Every destination it can send data to. And the point at which a limit, a human or a control would intervene.

Write those four down before the review rather than during it. The exercise routinely finds a tool nobody remembered granting, and it is cheaper to find it on a Tuesday than in front of a security team.

Blast radius is the design variable

Once compromise is assumed, the interesting quantity is how much damage a compromised agent can cause before something stops it.

Four dimensions bound it. What the agent may call, meaning the tool surface. What its credentials reach, meaning the data and systems in scope. Where it may send data, meaning egress. And how much it may do before a human or a limit intervenes.

Each of those is a place a control can be enforced, and none of them is the model. That is the structural insight this book keeps returning to: the model is not a control point, it is the thing being contained.

Chapter 2 turns this into a map, because you cannot bound a radius you have not drawn.

Autonomy is a spectrum, and it should be a stated position

Teams talk about agents as though autonomy were binary. It is a dial, and the position should be a deliberate decision recorded somewhere.

At the low end, the agent proposes and a human executes. Then the agent executes reversible actions and proposes irreversible ones. Then it executes everything within a bounded scope with sampled review. At the high end it operates unattended with after-the-fact audit.

Every step along that dial should be earned with evidence, which is what the evaluation apparatus in a companion volume exists to produce. Moving up the dial because the demo went well is the most common way an organisation acquires a risk it never assessed.

Write the current position down, per agent, alongside what would justify moving it. That sentence is also the one an auditor will ask for.

Accountability needs a name, not a team

The fourth property of a principal is the one that has no technical component and causes the most trouble.

Somebody has to answer for what the agent does. In practice that means a named person who approves its authority, reviews its incidents, and can order it stopped. A team is not sufficient, because a team is nobody at three in the morning.

Two adjacent decisions belong with the name. Who may change the agent's permissions, which should be a different person from whoever writes its prompts. And who may declare that it is misbehaving and pull the stop control from Chapter 12.

Where the organisation has an existing model for service ownership, use it. An agent that is registered like any other production service, with an owner, a runbook and an on-call rotation, inherits a decade of operational practice for free.

The compliance clock is now external

For some teams this stopped being an internal debate. The EU AI Act's implementation timeline states that the remainder of the Act starts to apply on 2 August 2026, with the exception of Article 6(1), and that Member States must have at least one operational regulatory sandbox by that date.

The earlier milestones are already behind us on that timeline: prohibitions and AI literacy from 2 February 2025, and general-purpose AI model obligations, governance and penalties from 2 August 2025. Article 6(1) applies from 2 August 2027, and public-authority high-risk providers from 2 August 2030.

This is not legal advice and this book does not offer any. The engineering point is narrower and unavoidable: for systems in scope, the artifacts an auditor will ask for are logs, oversight mechanisms and documentation, and those have to be designed in rather than reconstructed. Chapter 12 covers what to build.

If your systems are out of scope, the same artifacts remain the cheapest way to answer the security review that is coming anyway.

Chapter summary

An agent that holds credentials and takes actions is a principal rather than a feature, and a principal has four properties: an identity distinct from other actors, an authority someone deliberately granted, a record attributing actions to it, and a named person accountable for it. Most first deployments have none of the four, because the agent inherited the service account of the process it was built inside, which was scoped for a different purpose. Most of what follows is ordinary security applied to a new principal, with one genuine novelty: instructions arrive at runtime in text the agent cannot reliably distinguish from your own, and OWASP states plainly that fool-proof prevention of prompt injection is not currently apparent, so compromise is a normal operating condition rather than an incident. Excessive agency has three root causes, being excessive functionality fixed in the tool definition, excessive permissions fixed in identity and grants and enforced at the destination, and excessive autonomy fixed by approval and containment design. The threat model changes shape, because an attacker needs only to place text where the agent will read it, which is why OWASP published a separate agentic list on 9 December 2025 with more than a hundred contributors covering goal hijacking, tool misuse, memory poisoning, identity abuse, inter-agent communication and cascading failure. Blast radius becomes the design variable, bounded by tool surface, credential reach, egress and action limits, none of which is the model. Autonomy is a dial whose position should be recorded per agent with what would justify moving it, accountability needs a named person rather than a team, and for systems in scope the EU AI Act timeline puts most of the Act into application on 2 August 2026, which turns evidence from good practice into a requirement.

Before anything can be bounded it has to be drawn. Chapter 2 is Mapping Trust Boundaries in an Agentic System, which is the exercise of naming every principal, every data flow and every point where untrusted input enters, on one page, in an afternoon.