AI agent security protects the data, tools, identities, and resources available to an agent from misuse and unauthorized effects. It examines both what can influence the agent and what the surrounding system enables it to do.
AI agent governance defines delegated authority and the responsibilities for controlling it. Security adds the threat model: how that authority could be misused, which assets could be affected, and where an independent restriction can limit the effect. An instruction that changes the model's behavior does not need to create new privileges if an overpowered tool or credential is already available.
Start with an asset and a bounded task
Hypothetical example: a storage assistant is authorized to prepare a capacity report from usage records and related support tickets. One retrieved ticket contains an instruction, controlled by an adversarial contributor, to delete recovery snapshots in a production environment. The assigned task authorizes analysis, not deletion.
Suppose the runtime also exposes a maintenance tool and a service credential capable of deleting those snapshots. They exceed what the reporting task requires. The unwanted effect depends on the path from retrieved text to a proposed operation, the available authority, and the component that could execute the change. This is a hypothetical design, not an incident, product integration, or test result.
| Threat-model element | Scope in the hypothetical example |
|---|---|
| Asset | Recovery snapshots and the recovery options that depend on them |
| Adversarial source | A contributor who can influence a ticket the assistant retrieves |
| Entry point | Ticket content included as context for preparing the report |
| Trust boundary | Reference material being treated as authority to change production resources |
| Available capability | A maintenance operation and credential that can request deletion |
| Effect to constrain | Deletion outside the approved task and change process |
The impact must be assessed against the actual recovery design. A snapshot is not proof of a sufficient backup, and deleting one does not establish that recovery is impossible. Identify which recovery options would be lost, which independent copies exist, and what the storage system actually permits. The threat model should make those dependencies visible rather than invent a severity from the word “delete.”
Separate prompt injection from the authority to act
Prompt injection attempts to redirect a language-model application's behavior through instructions supplied in an input or external material. OWASP's Prompt Injection Prevention Cheat Sheet distinguishes direct input from indirect instructions embedded in content such as documents, tickets, or tool results. A retrieved source can be relevant to the task without being authorized to redefine it.
In the storage example, the malicious ticket tries to turn evidence for a report into a maintenance instruction. Receiving that text, proposing a deletion, and deleting a snapshot are different events. A security review needs to establish which of them occurred. The presence of an injection attempt does not prove successful influence or an external effect.
Preserve the distinction between trusted task instructions and external content, and inspect the actions proposed after that content is processed. Content screening can contribute a signal. It does not determine whether a particular service identity should be able to delete a production resource. A model used to screen another model's input also needs assessment; it does not become a trusted authorization boundary merely by being called a guardrail.
The same concern extends to stored context. If untrusted material is retained as a future instruction or mixed into another user's working context, the influence can persist beyond the original retrieval. Review where context is saved, who can modify it, and which later tasks can consume it. OWASP's AI Agent Security Cheat Sheet identifies memory poisoning and context isolation as agent security concerns.
Reduce tool capabilities and excess permissions
A tool is a route to an effect. Review its available operations and the authority it exercises, not only its display name. OWASP describes Excessive Agency through excessive functionality, permissions, or autonomy, including damage triggered by mistaken or manipulated model output. Security controls should address unwanted actions even when there is no proof of malicious intent.
For the reporting assistant, removing deletion from its tool set reduces the operations it can request through that interface. Restricting the destination credential to the reads needed for reporting constrains what that credential can do. These controls work at different points. A hidden maintenance button is not sufficient if the same runtime can still invoke the operation through a general API client or shell.
Review operations together with their targets and arguments. A maintenance function might be appropriate in one environment and prohibited in another. A valid resource identifier and a correctly formed request establish that an operation is intelligible to the API, not that the reporting task authorizes it. Argument validation and business authorization answer different questions.
Downstream authorization should independently restrict the caller's access. OWASP's excessive-agency guidance recommends enforcing authorization in the destination systems instead of relying on the model to decide what is allowed. A destination may legitimately accept a powerful service credential while the proposed action still exceeds the user's task. Reduce that mismatch rather than interpreting a successful API authorization as proof of appropriate agent behavior.
Protect data and credentials outside the prompt
An agent can expose information through a generated answer, tool arguments, a file it writes, or a request to another service. Threat modeling must identify the information, its permitted audience, and the paths by which it could leave that scope. Limiting the final chat response does not necessarily constrain a tool that already transmitted the same content.
Keep credential exposure and credential use distinct. A model does not need to see a service token to cause a tool to act with that token's permissions. Conversely, a credential copied into context, a generated file, or an activity record can create another exposure path. Review where secrets are obtained and held, which processes can read them, and what operations they authorize. A reference to a credential is preferable to copying its value into evidence.
Minimize the sensitive material made available to the task. For the capacity report, aggregate usage records may be enough; access to the contents of stored documents requires a separate justification. If the workflow can send reports elsewhere, identify the allowed destination and recipient scope. An approved domain alone may not identify the permitted account, folder, or audience within that service.
The governance and monitoring systems also process data. Retaining prompts, tool inputs, and full responses can create additional copies of restricted information. Define what an investigation needs, who can access it, and how long it should remain available. More collected content does not automatically produce a stronger explanation of an attack.
Treat shell and filesystem access as capabilities
A general shell interface can expose more operations than a task-specific tool. Its effective reach depends on process permissions, available programs, credentials, mounted filesystems, and network access. For the storage assistant, blocking one maintenance tool would leave a gap if the same permitted shell process could call the storage API with a deletion-capable credential.
Review file reads, writes, deletion, and execution separately. A task that can create a report should not acquire unrestricted access to unrelated files merely because both operations use the same filesystem. For coding agent governance, examine the scripts and repository content that commands will consume. Permission to invoke a familiar command name does not establish that every version of the referenced script is appropriate.
Isolation reduces only the capabilities its configuration actually excludes. A sandbox with a writable shared directory or an available production credential can still permit effects through those resources. Verify filesystem mounts, process identity, network paths, and reachable services against the intended task. Do not use the presence of a sandbox as a substitute for inspecting its boundary.
Review MCP servers and third-party tools as dependencies
MCP provides a protocol through which an application can obtain context and invoke tools. The security assessment still needs to identify the actual server, its tool implementation, the data it returns, and the credentials it uses. A server can supply information to the model and participate in operations against other systems, so review both directions of that relationship.
The MCP tools specification requires server input validation and access controls. It also treats tool annotations as untrusted unless they come from trusted servers. A description that calls a tool “read-only” is not sufficient evidence of its behavior. Review the implementation and permissions relevant to the operation, including the downstream systems it can reach.
The MCP authorization specification defines an HTTP authorization flow; support is optional for MCP implementations, and that flow is not the STDIO credential model. An authenticated connection to a server does not by itself authorize every business action exposed by that server. Check which identity and permissions apply when the server performs the external operation.
Treat a changed third-party tool as a potential change to the threat model. A new operation, broader credential, different destination, or altered response content can change the risk even if the user-facing tool name remains the same. Review how updates are selected and introduced, and keep a record of the version and configuration actually evaluated. A previous approval is not evidence about an unexamined replacement.
The MCP security and governance guide follows these relationships through a hypothetical inventory lookup, separating server access from permission to retrieve a particular record.
Combine policy controls with a review that can reject
A policy check should evaluate the proposed operation against the task's allowed effects using facts it can establish. In the storage example, production deletion falls outside the reporting task regardless of how persuasively the retrieved ticket describes a cleanup need. The evaluator needs the target, operation, executing identity, and delegation; the model's own description of the action is not enough.
Some changes need judgment from an authorized person. If the organization decides that snapshot removal should be considered, it should enter the appropriate maintenance approval process with the affected resources and recovery consequences visible. That is a different decision from approving the capacity report. Do not let an agent's urgency claim turn a review into automatic acceptance.
The reviewer should have evidence independent of the questionable source, such as the actual resource inventory and the applicable change policy. Present the action that would be performed, not merely the agent's summary of why it seems safe. The review must be able to reject or leave a request unresolved. Approval has value only when the executor respects its scope.
Failure behavior belongs in the control assessment. If a check becomes unavailable, determine which operations remain possible and which authorization is still required. The runtime governance pillar explains decision validity, application, and failure contracts. The architecture guide shows how these responsibilities cross component boundaries.
Use observability to investigate the whole attempt
Security evidence should help distinguish attempted influence, a changed proposal, use of a capability, and the resulting effect. For the storage scenario, a useful investigation would connect the retrieved ticket, the proposed operation, the policy response, the executor's behavior, and any observed storage result. These are evidence requirements for the hypothetical case, not records collected from a real incident.
An alert on the ticket can indicate suspicious instructions. A denied tool response can indicate that an adapter emitted a denial. Neither fact alone establishes that no other path performed the deletion. Investigate the operation and the boundaries actually covered, and leave unobserved outcomes unknown.
Keep enough provenance to examine a suspected source or tool change, while minimizing sensitive content in the record. Identify who can review the evidence and take follow-up action. If containment is needed, it may involve the underlying account, tool, process, or destination rather than only ending a conversation. Such actions require authority and verification of their own; an alert is not proof of containment.
Validate controls against the threat model
Use a controlled environment and synthetic resources to check whether the permitted reporting task still works and whether out-of-scope deletion is constrained. Examine an instruction in retrieved material, a proposed prohibited operation, a broader-than-needed credential, and an unavailable policy check. Inspect the actual executor and destination behavior, not only the text of the model's answer. These are proposed validation cases; no attack or product test was executed for this page.
Record what was tested, which input and operation paths were covered, and what remains uncertain. Revisit the assessment when the tool set, credentials, data sources, or execution environment changes. A detector result can be useful evidence for its tested inputs without establishing that every route to an unauthorized effect is controlled.
The analysis of an agent's security boundary explains how to retain prior findings within their conditions while assessing a changed tool or identity.
How KonaSense contributes to the security assessment
In the reviewed Claude Code PreToolUse implementation for Kona for Agents, a proposed tool operation can be submitted for policy evaluation. The adapter can return a denial, a request for user approval, or updated tool arguments. Its evaluation-error path falls back to Allow. The available effect must be assessed for that hook and the installed host behavior.
Those mechanisms can contribute a decision at a supported runtime point. They do not establish the filesystem isolation, credential restrictions, or destination authorization of the surrounding deployment. The snapshot scenario does not claim a supported storage integration or verified detection of its malicious instruction.
Assess the installed integration alongside the agent's tools, identities, data access, and destination controls. The relevant question is which part of the modeled path each mechanism can restrict, and what evidence establishes that restriction for the intended operation.