Agentic AI security begins with identity, authority, and effects

Threat model the complete execution path

Start with the assets and effects: confidential data, business records, code, payments, messages, infrastructure, approvals, and decisions. Then map every place untrusted content can influence the path: user input, retrieved documents, websites, tool metadata, memory, another agent, or an external API.

OWASP's 2026 agentic Top 10 and securing-agentic-applications guide organize recurring risks across goals, tools, identities, memory, communication, and cascading behavior. They are useful starting points, not a substitute for a system-specific threat model. [S1] [S2]

Treat model output as untrusted

A model can propose a plan, tool, argument, or delegation. The application must validate that proposal against policy and schema. Never construct executable commands, database queries, or privileged requests through unrestricted string concatenation.

Structured output reduces ambiguity but does not create authorization. Validate ranges, identifiers, data classifications, business rules, environment, and expected side effects outside the model.

Use task-scoped identity and least authority

Ambient service credentials make every prompt and retrieved document part of the security perimeter. Prefer short-lived, task-scoped identities with explicit tool, data, tenant, and environment restrictions.

• Separate read, propose, approve, and execute identities
• Bind permissions to the case and user rather than the agent name
• Prevent credential forwarding across agents unless explicitly authorized
• Revoke or expire capabilities after the task or approval window
• Record the identity and policy used for every side effect

Indirect prompt injection is an authorization problem

Retrieved content can contain instructions that conflict with the user's goal or system policy. Detection is useful, but the durable control is to prevent content from acquiring authority merely because it appeared in context.

NIST's agent-hijacking evaluation work studies this class of manipulation. The architecture should label sources, isolate untrusted content, constrain tools, verify the plan, and require review for consequential transitions. [S3]

Protect memory and shared state

Memory poisoning can persist an attack beyond one interaction. Validate which components may write reusable memory, retain provenance, classify trust state, and support supersession or quarantine. Shared multi-agent workspaces need per-role write permissions and conflict visibility.

Constrain delegation and agent communication

A delegated task should carry the original task identifier, scope, authority, evidence boundary, budget, and completion criteria. The receiver should authenticate the sender and reject instructions outside the delegated envelope.

A2A and MCP can standardize transport and capability discovery, but they do not decide whether two parties should trust each other. [S5] [S6] [S4]

Contain tools and execution environments

Place high-risk tools behind policy-enforcing gateways. Use sandboxing, network egress controls, filesystem boundaries, rate limits, resource quotas, and separate environments. An agent that can run code should not automatically gain production credentials or broad network access.

Monitor trajectories and cascade risk

Security telemetry should correlate the entire run: source retrieval, plan, policy result, tool calls, messages, retries, memory writes, and final effects. Alert on unusual delegation, privilege escalation attempts, repeated denials, budget spikes, cross-tenant access, and rapid tool chains.

Multi-agent systems need containment boundaries so one compromised participant cannot recruit the rest of the team or poison a shared decision. A global stop and credential revocation path should remain available outside the agent coordination layer.

Research boundary

This article is defensive architecture guidance. It is not a penetration test, compliance opinion, or guarantee that a design is secure. Production systems need threat modeling, secure implementation, operational monitoring, and independent review appropriate to their risk.