The threat model you have was written for software
Traditional application security assumes the thing you are defending follows its instructions. An agent takes instructions from whatever text reaches it, holds credentials, calls other systems, and can be persuaded. The controls that worked for deterministic software do not map cleanly onto that.
So security teams end up in an uncomfortable position: asked to approve something quickly, without an established threat model, a shared vocabulary for the risks, or a way to evidence what happened afterwards. Blocking is unpopular. Approving without those things is worse.
Making agent risk something you can reason about
The work is usually a mix of threat modelling, control design and getting the evidence story straight before a review rather than during one.
Agent threat modelling. Working through what your agents can reach, what an attacker would do with that access, and which of your existing controls still apply. Grounded in your actual estate rather than a generic checklist.
Prompt injection and tool misuse. Where untrusted content can reach an agent, what it could make that agent do, and which mitigations are worth the cost. Includes the indirect paths through documents, tickets and retrieved content that teams tend to miss.
Least privilege for non-human callers. Most agents hold far more access than their job needs, because the credential to hand was the broad one. We work through what each agent genuinely requires and how to get from here to there without breaking things.
Auditability and evidence design. Deciding what has to be recorded, in what form, and where it lands, so that a question six months later has an answer. This is the part that usually gets designed last and should be designed early.
Human oversight that works. Which actions stop for a person, who that person is, and how they are given enough context to make a real decision rather than rubber-stamping a queue.
Getting through the review. Preparing the material your own risk function, auditors or regulators will ask for, and rehearsing the questions before they are asked in a meeting that matters.
Threat model first, controls second, evidence third
Doing these in the wrong order is the common mistake. Controls chosen before the threat model tend to be the ones a vendor was selling.
Map what exists and what it can reach
The agents running, the systems they touch, the credentials they hold, and who owns each one. Frequently this stage alone changes the conversation, because the estate is larger than the register suggested.
Model the threats that apply
What could go wrong given that specific estate, ordered by plausibility and blast radius rather than by how alarming it sounds. We are explicit about the risks we think are overstated as well as the ones that are not.
Design the controls and the evidence
What to enforce, where to enforce it, and what record it leaves behind. Delivered as something your engineering team can implement and your risk function can accept.
Something your risk function will actually accept
- A threat model written against your estate, not a generic one
- An inventory of agents, the systems they reach and the access they hold
- A control design covering identity, policy, approval and containment
- An evidence and logging design mapped to the questions you will be asked
- A prioritised remediation plan with effort and impact against each item
- The risks you are choosing to accept, written down rather than implied
Related: the KPATH platform, agent discovery, what the EU AI Act asks of agent estates.