SXF SECURITY REFERENCE / AGENTIC AI
AI Agent Security in 2026:
Prompt Injection, MCP, Permissions & Sandboxing
AI agents can read private data, call tools, execute code, browse the web and act across business systems. That makes security a systems problem, not a prompt-writing problem. This living reference explains how to secure the complete agent stack — from untrusted context and MCP tools to identities, secrets, sandboxes, approvals, telemetry and incident response.
Secure AI agents by assuming the model can be influenced — then make sure influence does not automatically become authority.
The strongest design is layered: treat web pages, email, documents, RAG results and tool outputs as untrusted; give each agent a managed identity with least-privilege permissions; allow only approved tools and actions; isolate code and browser execution; keep secrets outside the model context; require human approval for high-impact actions; and log every tool call, authorization decision and external side effect. Prompt-injection detection helps, but it is not a substitute for architectural controls.
DEFINITION
What is AI agent security?
AI agent security is the practice of protecting systems in which a model can do more than generate text. An agent may browse websites, read documents, access databases, call APIs, execute code, use credentials, communicate with other agents or change real-world systems. Security therefore has to cover the complete path from input to action.
A conventional chatbot can still leak data or produce harmful output, but an agent adds agency: the ability to choose and chain actions. The security question changes from “can the model say something unsafe?” to “what can the system read, decide, invoke, modify and persist — and what happens if any part of that loop is manipulated?”
NIST's 2026 analysis of AI agent security says established cybersecurity practices remain relevant but need adaptation for agent systems, because model outputs are being connected to software capabilities and real-world actions. Agent security is not a replacement for ordinary application security. It is application security plus new control problems created by autonomy, tool use and untrusted context.
The SXF topic page tracks security, sandboxing and cyber-defense updates from primary sources.
THREAT MODEL
Why AI agents change the security model
Agents collapse boundaries that traditional software usually keeps separate. The same workflow can ingest untrusted content, reason over private information, choose a tool, acquire authority and create an external side effect. A problem at the context layer can therefore become an authorization problem, a data-loss problem or a production incident.
Untrusted context
Web pages, email, documents, retrieved text and tool output can contain instructions the system should not trust.
Probabilistic decisions
The model interprets intent and context rather than executing a fixed deterministic rule set.
Real authority
Tools, APIs, browsers and credentials can turn an incorrect decision into a real side effect.
Persistent state
Memory, task history and shared context can carry compromised or incorrect information into future runs.
The risk is therefore a product of both influence and blast radius. A model that reads hostile content but has no sensitive permissions presents one class of risk. The same model connected to email, repositories, cloud infrastructure and payment systems presents another.
ARCHITECTURE
A secure AI agent architecture: five control planes
A strong production design separates what the model sees from what the system allows. Instead of asking the model to police itself, place controls around the model at every transition where data, authority or side effects cross a boundary.
Classify input by trust
Keep system instructions, user intent, retrieved data and third-party content distinct. A webpage should never silently become policy.
Know which principal is acting
Give the agent a dedicated identity and track whether an action is agent-owned, delegated or temporarily elevated.
Expose only approved capabilities
Bind the agent to a curated tool set, validate parameters and re-authorize every call in the downstream service.
Contain code and browser activity
Use isolated environments, restricted filesystems, network policy and resource quotas to reduce blast radius.
Observe, approve and revoke
Require confirmation for consequential actions, preserve logs and maintain a tested path to disable identities and roll back changes.
Least privilege limits what an agent can access. Least agency also limits how independently it can decide and act. High-risk workflows need both.
OWASP 2026
OWASP Top 10 for Agentic Applications: the security map
OWASP's 2026 framework is useful because it treats agentic security as more than prompt injection. It covers goals, tools, identity, supply chain, execution, memory, inter-agent communication, cascading failures, human trust and rogue behavior.
| Risk | What it means in practice | Primary control direction |
|---|---|---|
| ASI01Agent Goal Hijack | Untrusted instructions can redirect the agent's objective or decision path. | Separate data from instructions, constrain actions and gate high-impact steps. |
| ASI02Tool Misuse & Exploitation | A legitimate tool can be invoked in the wrong context or with unsafe parameters. | Tool allowlists, schema validation, action policy, rate limits and least privilege. |
| ASI03Identity & Privilege Abuse | Agent identities or delegated credentials provide more access than the task needs. | Dedicated identities, scoped roles, short-lived entitlements and downstream authorization. |
| ASI04Agentic Supply Chain Vulnerabilities | Models, packages, skills, MCP servers or tools can introduce untrusted behavior. | Verify provenance, inventory components, review updates and isolate third-party tools. |
| ASI05Unexpected Code Execution | Generated or retrieved code can execute outside the intended boundary. | Sandboxing, egress controls, ephemeral environments, restricted mounts and quotas. |
| ASI06Memory & Context Poisoning | Persistent context can be changed so future decisions rely on compromised state. | Memory isolation, provenance, write policy, expiry and review of high-trust state. |
| ASI07Insecure Inter-Agent Communication | Agents can over-trust messages or capabilities received from other agents. | Authenticate agents, authorize each hop and propagate tenant and trust boundaries. |
| ASI08Cascading Failures | One incorrect result can propagate through a multi-step or multi-agent workflow. | Bounded retries, independent verification, circuit breakers and transaction limits. |
| ASI09Human-Agent Trust Exploitation | Users can over-trust plausible outputs or low-context approval prompts. | Context-rich approvals, exact targets, provenance and anti-fatigue design. |
| ASI10Rogue Agents | An agent can drift outside intended behavior or governance boundaries. | Runtime policy, monitoring, revocation, kill switches and bounded autonomy. |
Risk names follow the OWASP Top 10 for Agentic Applications 2026. The summaries above are SXF implementation notes; use the OWASP source for full definitions and examples.
PROMPT INJECTION
Prompt injection in AI agents: why it becomes an authorization problem
Prompt injection occurs when content processed by a model contains instructions that compete with the user's intent or system policy. In an agent workflow, the content can come from a webpage, document, email, repository issue, retrieval result or tool output.
The most important distinction for autonomous systems is indirect prompt injection: the instruction is embedded in external content the agent encounters while doing legitimate work. Anthropic has described browser use as especially exposed because every page is potentially untrusted, and OpenAI explicitly warns that agents connected to logged-in sites and apps face prompt-injection risk.
How to reduce prompt-injection impact
Separate instructions from data
Preserve provenance and trust labels so retrieved text is treated as evidence, not authority.
Constrain tool choice
A model that can be influenced should not have an unrestricted menu of sensitive actions.
Validate action intent
Compare the proposed action with the user's stated goal and policy before execution.
Minimize exposed secrets
Do not place raw credentials or unnecessary sensitive data in model-visible context.
Gate irreversible actions
Require confirmation for important sends, writes, purchases, access changes and deletions.
Assume detection can fail
Model training and classifiers reduce risk; architecture must still contain a successful injection.
MODEL CONTEXT PROTOCOL
MCP security: tools, authorization and trust boundaries
MCP has become an important connector layer for agentic systems, but a protocol connection is also a trust relationship. An MCP server can expose tools, resources and prompts that influence the agent's behavior. Server provenance, authorization and tool governance are therefore security-critical.
The MCP 2026-07-28 specification added authorization hardening, including issuer validation aligned with RFC 9207 and a shift toward client metadata documents. The revision also exposes method and tool names in HTTP headers, giving gateways a cleaner place to apply routing, metering and authorization policy.
Inventory origin, owner, code provenance and update process. Third-party servers should be treated as third-party software with privileges.
Use explicit scopes, issuer validation, short-lived credentials and per-resource authorization instead of broad tokens.
Tool metadata enters model context. Review changes to critical tool descriptions and capabilities.
Attach credentials at the approved execution layer rather than exposing raw secrets to the model.
Tool output is another untrusted input that can affect the next decision in the agent loop.
Repository access, shells and deployment tools make coding agents a high-value security boundary.
IDENTITY & ACCESS
AI agent identity, permissions and secrets: apply least privilege at every hop
Microsoft's 2026 security guidance recommends treating each agent as a first-class principal: a dedicated, lifecycle-managed identity with a named owner, explicit purpose and narrowly scoped roles. This is stronger than sharing a user's token or a generic service account across multiple agents.
Permissions should be constrained by resource, data and operation. A research agent may need read access to one collection but no export right. A remediation agent may need write access to a specific ticket type but no identity-administration permission. Elevated authority should be temporary and expire automatically.
Make actions attributable and revocable. Record a human owner and purpose for every production agent.
Design roles around discrete operations instead of giving broad team or administrator access.
Grant temporary higher privileges only when the workflow reaches a justified step.
Store credentials in a secrets system and bind them to approved actions.
APIs should validate identity, role and scope independently instead of trusting the orchestrator implicitly.
Practice disabling the identity, expiring tokens and rolling back common unintended changes.
EXECUTION SECURITY
AI agent sandboxing: contain code, browsers and untrusted files
An agent that can execute code or operate a browser should not run with unrestricted access to the host, production network or developer secrets. Sandboxing is a blast-radius control: it assumes code or browser behavior may be wrong and limits what the failure can reach.
Ephemeral execution
Create disposable environments for tasks and reset them instead of accumulating state indefinitely.
Restricted filesystem
Mount only required files and keep host credentials outside the execution environment.
Network egress policy
Allow only destinations required for the task where practical.
Resource quotas
Bound CPU, memory, runtime, disk and request volume to contain runaway behavior and cost.
Separate credentials
Use task-scoped, short-lived credentials rather than inheriting the operator's environment.
Artifact review
Inspect diffs, generated files and external side effects before promoting output into production.
MEMORY SECURITY
Memory poisoning and context integrity in long-running agents
Persistent memory changes the attack window. Incorrect or malicious content can become durable context that influences later tasks. Memory can also create cross-user or cross-tenant exposure if isolation is weak.
Protect memory like a data store with varying trust levels. Track what wrote each item, which task it came from, whether it contains user-supplied or external content, how long it should live and whether it may influence high-impact decisions.
Future reasoning should distinguish user-approved facts from retrieved or inferred content.
Validate or require approval before storing sensitive instructions or identity-related state.
Convenience caches should never become a cross-context contamination channel.
Use lifecycle policy so outdated or compromised state does not become permanent authority.
SUPPLY CHAIN
Secure the agentic supply chain: models, tools, skills, packages and MCP servers
Agents depend on a broader supply chain than most applications. One task may involve a model, orchestration framework, skill package, browser environment, MCP server, code dependency, SaaS API and retrieved content. Any of these components can change what the agent sees or what actions are available.
Maintain an inventory of components with executable or instructional influence. Review changes to tool descriptions, prompts and skills the same way you review code changes. For critical agents, approve dependencies, verify provenance and stage updates before production.
Microsoft notes that tool descriptions themselves enter the model's working context. Changes to tool metadata should therefore be treated as security-sensitive changes, not mere documentation edits.
MULTI-AGENT SYSTEMS
Multi-agent security: do not turn delegation into implicit trust
When one agent delegates to another, the receiving agent should not automatically inherit the sender's trust level, permissions or assumptions. Treat each agent-to-agent exchange as a new security boundary.
Authenticate agents
Know which agent produced a message or requested a capability.
Authorize each hop
Delegation should not silently create broader effective permissions.
Propagate provenance
Carry trust labels and source information with shared context and artifacts.
Bound recursion
Limit delegation depth, retries, execution time and cost.
Verify critical results
Use independent checks before one agent's output triggers a high-impact action elsewhere.
Contain cascading failures
Use circuit breakers and transaction boundaries so one error cannot fan out indefinitely.
The architecture guide covers orchestration, memory and control topologies.
HUMAN IN THE LOOP
When AI agents should require human approval
Approval is most valuable when it sits at a real commitment boundary. Asking a human to approve every low-risk read creates fatigue; skipping approval before a payment or production change creates unacceptable blast radius.
Purchases, transfers, paid commitments and changes that materially increase spend.
Require approvalSending email, publishing, submitting forms or speaking on behalf of a user or organization.
Require approvalDeleting records, revoking access, overwriting data or making difficult-to-reverse modifications.
Require approvalDeployments, infrastructure changes, secret rotation and privileged administration.
Require approvalSharing private information externally or moving data across trust boundaries.
Require approvalA good approval screen should show the exact target, action, relevant parameters and meaningful consequences. A vague “Allow agent to continue?” prompt is not enough context for a high-impact decision.
OBSERVABILITY
AI agent logging, monitoring and incident response
Logging only the final model response is not sufficient. A useful audit trail reconstructs the chain of authority and side effects: which identity acted, on whose behalf, under which role, with what effective scope, what tool was called, what resource changed and what the outcome was.
Identity & delegation
Agent ID, delegating user or service, role and active entitlements.
Context provenance
Source labels for web, files, memory and retrieved records used by the workflow.
Tool calls
Tool name, arguments, authorization result, target resource, timestamps and correlation IDs.
Side effects
Writes, sends, deployments, purchases, access changes and externally visible actions.
Behavior drift
New endpoints, unusual parameters, abnormal call volume or unexpected action sequences.
Revocation & rollback
Disable agent identity, invalidate tokens, stop execution and restore known-good state quickly.
ASSURANCE
How to red-team an AI agent before production
Red teaming should exercise the whole agentic system, not only the model. The goal is to verify that security layers continue to work when context is untrusted, tools behave unexpectedly, permissions are stressed and workflows run for many steps.
Confirm that external pages, files and messages cannot silently redefine system policy.
Verify that disallowed tools and unsafe action combinations remain blocked.
Confirm the agent cannot exceed the resource, data or operation scope assigned to its task.
Verify that sensitive information remains inside approved destinations and trust zones.
Check that low-trust observations cannot become durable high-trust instructions without policy.
Validate filesystem, network, runtime and credential isolation around execution environments.
Ensure changes to tools, servers, skills and metadata are visible and reviewed.
Confirm reviewers see the exact target and consequence of a high-impact action.
Verify one incorrect component cannot propagate indefinitely through a multi-agent workflow.
Confirm budgets, retry caps and execution windows prevent runaway tasks.
DEPLOYMENT CHECKLIST
AI agent security checklist for production
RISK BY WORKFLOW
AI agent security priorities by use case
External pages are untrusted. Limit sensitive apps, logged-in sites, downloads and consequential browser actions.
Protect shell credentials, repository permissions, package installs, network access and deployment paths.
Scope connected apps and write actions; require approvals for customer, financial and permission changes.
Protect account data and prevent the agent from granting access based only on conversational claims.
Authenticate every agent, constrain delegation and independently verify high-impact outputs.
Use strict budgets, behavior monitoring, execution windows and a tested shutdown path.
Compare execution environments, autonomy, pricing and governance in the broader SXF agent guide.
FAQ
Frequently asked questions about AI agent security
What is AI agent security?
AI agent security protects systems in which a model can take actions, use tools and access data. It combines identity, authorization and isolation with agent-specific controls for untrusted context, tool use, memory and autonomy.
What is the biggest security risk for AI agents?
The most dangerous pattern is usually a combination: untrusted input influences an agent that has enough authority to cause harm. Prompt injection becomes materially more dangerous when permissions and blast radius are broad.
Can prompt injection be completely prevented?
No current control should be treated as complete prevention. Secure systems reduce the chance of manipulation and also limit what an influenced agent can access or do.
Is MCP secure?
MCP can be deployed securely, but an MCP server or tool is not trustworthy merely because it uses MCP. Security depends on server provenance, authorization, scopes, credential handling, tool behavior and client policy.
Should an AI agent have its own identity?
For production systems, a dedicated managed identity improves least privilege, attribution, revocation and auditability.
When should an AI agent require human approval?
Approval is appropriate before difficult-to-reverse or externally consequential actions such as sending, publishing, purchasing, deleting, granting access, changing production systems or exposing sensitive data.
What should be sandboxed in an AI agent?
Agents that execute generated code, shell commands, browser automation or untrusted files should use an isolated environment with restricted mounts, network policy, resource limits and separate credentials appropriate to the risk.
What is memory poisoning in AI agents?
Memory poisoning occurs when incorrect or malicious content enters persistent memory or reusable context and influences later decisions. Controls include isolation, provenance, write validation, expiration and revocation.
How do you red-team an AI agent?
Test the complete system rather than only the model: untrusted content handling, tool policy, permission boundaries, memory, sandboxing, supply-chain changes, approvals, failure containment and cost limits.
What is the difference between AI safety and AI security?
AI safety is broader and includes reliability, alignment and harmful behavior. AI security focuses on adversarial and operational threats such as unauthorized access, prompt injection, compromised tools, data exposure, privilege abuse and unsafe execution.
PRIMARY SOURCES
Official sources used for this AI agent security guide
SXF prioritizes standards bodies, protocol specifications and first-party security documentation. Vendor descriptions of their own safeguards are treated as descriptions of implemented controls, not independent proof that agent compromise is solved.