AI Agent Security Risks: Build an Operational Threat Ledger

The practical way to handle AI agent security risks is to threat model each side effecting operation before the tool call. Record which asset can change, which identity supplies authority, which scopes are required, where the instruction came from, how the effect will be bounded, and what evidence makes a retry safe. If any field is unknown, stop at that boundary instead of asking the model to infer permission. This produces a useful decision, not another risk list. The operator can proceed, narrow a credential, remove surplus permissions, review an untrusted instruction, define an effect limit, or reconcile an ambiguous result before retrying. A valid tool response is not enough: security depends on the authority used and the external effect produced. Threat model the operation, not only the model An agent is more than an LLM. It joins a model, runtime, credentials, tools, external content, and destination systems into one action path. The Security of AI Agents paper makes this distinction explicit: agents use model generated actions to invoke tools that can affect real systems, creating confidentiality, integrity, and availability concerns beyond model alignment. Start with one proposed operation and draw four boundaries: 1. Instruction boundary: user intent, retrieved content, tool output, and memory enter the model context. 2. Authority boundary: the runtime attaches an identity or credential to the proposed tool call. 3. Effect boundary: the tool can read or change an external resource. 4. Retry boundary: uncertain transport or tool results may cause the runtime to repeat an effect. The OWASP Agentic Security Initiative describes its guidance as a threat model based reference for emerging agentic risks. That is the right starting posture: identify assets, actors, trust changes, and possible effects before choosing controls. Use a run level threat ledger rather than free form notes: Do not put secret values in the ledger. Store references, issuer and audience identifiers, expiry, scopes, operation identity, and evidence locations. The artifact should answer “what could this run change, under whose authority, and how will we know?” without becoming another credential leak. The reasonable default is to create one ledger row per external operation. A general agent level threat model still helps with architecture, but it cannot tell you whether this particular payment, message, release, or file mutation is safe now. Audit credential identity before checking the prompt A credential is not safe merely because it authenticates. For each operation, record: who or what the credential represents; where it was issued and where it may be presented; whether it is shared across agents or environments; its expiry and revocation path; the exact resource audience; a non secret reference that lets an operator rotate it. The June 2025 MCP authorization specification is concrete about the HTTP boundary. Clients include a resource indicator, servers validate that a token was issued for the intended audience, and invalid or insufficient authorization receives an error. The related MCP security guidance forbids token passthrough and explains why audience confusion weakens controls, attribution, and trust boundaries. Those rules apply directly to MCP HTTP authorization. The operating principle also travels well: never let one opaque token silently stand for every destination. A shared administrator token with no task owner and no narrow audience may work perfectly while destroying attribution and enlarging the blast radius. Credential health and instruction safety are separate. A clean prompt cannot repair an expired token, and a valid token does not make an untrusted instruction legitimate. Check credential evidence first because every later control depends on knowing which identity will cross the tool boundary. When evidence is missing, use stop credential , not “probably authorized.” The repair is mechanical: issue a short lived, revocable credential for the exact agent, task, audience, and environment. Keep the model out of that decision. Compare required permission with granted permission Least privilege becomes testable only when you compare two sets for one operation: If surplus is non empty, stop and replace the grant. An allowlisted tool is not enough. The same tool client may carry scopes unrelated to the current job, and those dormant permissions become available when context is poisoned, a tool argument is substituted, or the model simply chooses the wrong operation. Also reject missing required scopes. That case is usually less dangerous than surplus authority, but it creates noisy retries and encourages unsafe workarounds such as swapping in a broader credential. A permission mismatch should produce one explicit state and one repair, not an invitation for the agent to hunt for stronger secrets. Permission checks need an effect description. “Use the repository tool” is too broad; “create one release candidate in repository X” provides a resource and impact ceiling. Bind approval, if required, to that frozen description. Human review is valuable for high impact or untrusted operations, but a person should not be asked to approve an action that still has unnamed resources or unlimited effects. This is where a threat model differs from a guardrail implementation. The threat ledger identifies the authority and effect that require protection. Policy, approval, sandboxing, and verification are controls selected afterward. Starting with controls alone often leaves teams protecting the prompt while an overpowered credential remains unchanged. Treat instructions, effects, and retries as separate risks External content can influence an agent without becoming authority. Mark instruction provenance as trusted , untrusted external content , or mixed . If untrusted content contributes to a side effecting action, freeze the proposed resource and arguments, then require a policy decision or human review outside that content path. Do not solve this by deleting every external instruction. An agent may need retrieved documents or tool output to work. The security boundary is whether that content can silently choose a privileged effect. A read only analysis and a public message send should not share the same review rule. Next, define the effect independently of the tool response: exact destination resource; maximum number or size of changes; reversibility and rollback owner; stable operation identity; authoritative read back or other outcome evidence. Retries deserve their own row because a timeout does not mean “nothing happened.” The AWS Builders’ Library guidance on idempotent APIs shows how a stable client request identifier can make repeated requests semantically equivalent. That contract supports safe default retries. It does not authorize the original action, and it does not help if the runtime generates a new identifier for the second attempt. After an ambiguous timeout, use this order: 1. keep the original operation identity; 2. query the authoritative destination; 3. classify the effect as present, absent, partial, or unknown; 4. retry only when the contract makes another attempt safe; 5. verify the promised outcome after the final attempt. If the destination offers neither idempotency nor effect lookup, the correct state is reconcile before retry . That may require a person. It is still better than turning missing transport evidence into a duplicated payment, message, release, or deletion. Replay the nine case threat ledger The accompanying fixture makes the decision rule inspectable. security risk cases.json contains nine proposed operations. evaluate ai agent threat ledger.mjs checks boundaries in a fixed order: 1. credential presence, expiry, sharing, revocability, and audience; 2. required scopes against granted scopes; 3. untrusted instruction provenance for writes; 4. resource and maximum effect definition; 5. operation identity, idempotency, and reconciliation before retries; 6. independent effect evidence. Run it with: The reproduced summary is: Only two cases proceed. One is a bounded read. The other is an idempotent write with an exact audience, exact scope set, named resource, maximum impact, and independent evidence. The remaining cases demonstrate a shared administrator credential, an expired task token, a surplus delete scope, an unreviewed external instruction, an unbounded export, a retry with a new operation identity, and a success response without effect proof. Order matters. If permission is checked before credential audience, a cross service token may appear safe because its scopes happen to match. If effect evidence is checked before retry identity, the operator may label the run merely incomplete while another unsafe attempt is already possible. The first unsafe trust boundary should determine the disposition. Adapt the fixture with your real scopes and effects. Add a missing revocation path, wrong environment, stale approval, resource substitution, partial write, rollback failure, and disagreement between tool output and destination state. The goal is not to predict every attack. It is to make authority and uncertainty impossible to hide inside one green agent status. Keep the threat model operational Review the ledger when a tool, scope, credential issuer, destination API, retry policy, or instruction source changes. Do not require a full workshop for every run; generate most fields from tool schemas, identity metadata, policy, and operation receipts, then ask a person only about impact or uncertainty that code cannot resolve. The compact decision rule is: Proceed only when identity is audience bound, permissions equal the required set, untrusted instructions cannot silently authorize effects, impact is bounded, retries preserve operation identity, and the destination can prove the result. This rule has limits. Metadata can lie or become stale. An exact scope may still permit a dangerous argument. Idempotency may expire. A read back channel may be compromised with the writer. The ledger therefore reduces ambiguity; it does not prove the whole system secure. Pair it with downstream authorization, isolation, audit logs, testing, and incident response appropriate to the impact. Sidewisp is currently in private preview. It is intended as a health layer around existing agent runtimes, but production agent health collection and recovery are not shipped in the current website repository. This threat ledger pattern is something operators can implement in their own runtime now, not a claim that Sidewisp currently secures or monitors live agents. If you are evaluating Sidewisp for future agent health workflows, join the private preview. Until then, keep the threat ledger close to the tool boundary and let unknown evidence stop the action before it becomes an incident.