Design production security for AI agents

An AI agent combines uncertain decisions with real authority. It reads user input and retrieved content, plans across several steps, calls tools, writes memory, and may delegate work. Security cannot depend on the model consistently recognizing which text is trustworthy.

Build the agent so that a wrong or manipulated plan reaches a narrow enforcement boundary. The objective is not to eliminate every bad proposal. It is to prevent an invalid proposal from becoming an unauthorized side effect.

Draw the production trust boundaries

Separate these components even if they begin in one service:

• Context builder: retrieves user, application, and external content.
• Planner: proposes steps and tool calls.
• Policy decision point: evaluates identity, scope, target, and approvals.
• Tool gateway: validates schemas and invokes allowed operations.
• Sandbox: executes code or transforms files with bounded resources.
• Memory service: stores typed, scoped, and expiring state.
• Action ledger: records proposals, decisions, and external outcomes.

Mark every crossing with an authenticated identity and structured data. Natural-language content can inform a proposal, but it must not create a permission, approval, or tenant identity.

The OWASP Agentic Security Initiative catalogs agent-specific risks around goals, tools, identity, supply chains, code execution, and memory. Translate those categories into controls at your actual boundaries.

Give each run a bounded identity

Do not let all agent runs share one powerful service account. Bind a run to the initiating user or service, tenant, purpose, and expiry. Mint short-lived credentials for the small set of tools it can use. Re-evaluate authorization when the run resumes after a pause because the user's access or the target state may have changed.

Delegation must attenuate authority. A specialist agent should receive the intersection of the parent run's permissions and the permissions required for the subtask. It should never gain access merely because its own service identity is broader.

Kubernetes RBAC guidance warns that permission to create workloads can indirectly expose other resources in a namespace. Treat code execution and pod creation as high-authority tools even when the direct API verb appears narrow.

Put a policy gateway in front of tools

Expose specific operations rather than a generic shell or unrestricted HTTP client. A tool named get_run_metrics is easier to authorize and validate than request_url. Define allowed arguments, target patterns, response limits, and side-effect class in the tool registry.

At invocation time, verify:

1. The tool is enabled for this application and run.
2. The current principal can perform this action on this exact target.
3. Required approval exists in trusted application state.
4. Arguments satisfy deterministic policy and schema checks.
5. The operation fits remaining time, cost, and action budgets.
6. A retry cannot duplicate a non-idempotent side effect.

OWASP describes excessive agency as excessive functionality, permissions, or autonomy. Its guidance on excessive agency reinforces the same design rule: reduce the functions an agent can call, the permissions behind them, and the actions it can complete without review.

Treat memory and retrieved content as untrusted

Scope memory by tenant, user, application, and purpose. Store typed facts with provenance and expiry instead of appending arbitrary conversation text to a shared vector index. Validate sensitive facts against an authoritative system before using them in an action.

Retrieved pages, issue descriptions, emails, logs, and tool responses can all contain injected instructions. Label their source and keep them separate from system policy. A statement inside a document such as “approval granted” must not satisfy the approval check.

Test cross-session and cross-tenant retrieval, stale grants, poisoned summaries, and deletion. When memory changes, preserve who or what wrote the entry and why it was selected for a later run.

Isolate code and network access

When agents execute code, use an ephemeral sandbox with a read-only base, non-root identity, resource limits, a controlled working directory, and no ambient cluster or cloud credentials. Destroy the environment after collecting the declared outputs.

Default-deny network access and allow only the endpoints required for the task. Kubernetes NetworkPolicies can restrict ingress and egress at the pod level when supported by the cluster's network implementation. Sensitive workloads may also need separate nodes or stronger runtimes, as described in the Kubernetes security checklist.

Make consequential actions interruptible

Require human approval for actions with high blast radius, ambiguous targets, or weak rollback. Show the approver the exact target, structured arguments, expected effect, evidence, and expiry—not only the agent's summary.

Add stop controls outside the agent process: revoke its token, disable a tool, cancel a run, quarantine its output, and block further egress. Set maximum steps, elapsed time, tokens, parallel branches, and spend. These limits contain loops and cascading multi-agent failures even when individual calls appear valid.

Verify both proposals and outcomes

Log the ordered trajectory, but distinguish proposed, denied, attempted, and completed actions. Verify external state after a write and preserve the operation identifier. A model saying “done” is not evidence that a transaction occurred, and a timeout is not evidence that it did not.

Use Polyaxon artifacts to preserve sanitized fixtures, trajectories, policy decisions, and outcome ledgers. Record invalid proposals, completed prohibited actions, legitimate task success, denials, budget stops, and recovery time with tracking. Orchestrate regression suites through pipelines.

For adversarial test design, continue with How to red team AI agents. Testing finds failures; the boundaries above ensure those failures remain observable and contained in production.