Architecture for Secure Agent Tool Execution with Policy Enforcement

Secure agent tool execution begins by treating the model as a proposal generator, not an authorization authority. The agent may select a tool and assemble arguments, but deterministic services must establish identity, validate intent, enforce policy, obtain approval, issue least-privilege credentials, constrain execution, and record the result.

Put one policy gateway in every path to an effect. Prompt rules and agent-level guardrails are valuable signals, but they cannot replace call-time authorization at the tool boundary. A delegated subagent, resumed workflow, direct API client, or compromised prompt must encounter the same enforcement point.

Define principals, resources, actions, and consequences

Model the authorization request independently of natural-language tool descriptions. Identify the end user, tenant, agent application, delegated workflow, tool, action, target resource, requested data fields, and intended side effect. Add risk attributes such as reversibility, financial impact, external communication, privilege change, data sensitivity, and novelty.

Distinguish authentication from delegation. A valid agent service identity proves which service called the gateway; it does not prove the end user authorized a transfer or that the agent may read every resource the service can reach. Carry a verifiable delegation chain and evaluate both service and user policy.

Define deny-by-default tool registration. A newly connected tool should not become executable merely because its schema is discoverable. Promotion into a workflow requires an owner, data classification, risk tier, allowed principals, credential mode, network policy, idempotency contract, and test evidence.

Normalize an untrusted tool proposal

Validate the tool name against a trusted registry and the arguments against the registered schema. Canonicalize identifiers and URLs before policy evaluation so equivalent values cannot receive inconsistent decisions. Reject unknown properties when the tool contract allows it, cap string and collection sizes, and keep untrusted content distinct from instructions.

The MCP tools specification defines tool discovery and schemas while warning clients to treat annotations from untrusted servers as untrusted. Tool metadata can inform a display, but the policy gateway should use its own trusted risk catalog rather than accepting a server's claim that an operation is harmless.

A proposal envelope can make the authority boundary concrete:

type ToolProposal = {
  proposalId: string;
  principalId: string;
  tenantId: string;
  workflowId: string;
  toolRegistryVersion: string;
  toolName: string;
  canonicalArguments: Record<string, unknown>;
  requestedAt: string;
  logicalOperationId: string;
};

Do not include reusable credentials in this object. Store a hash of canonical arguments for approval and audit, while retaining sensitive cleartext only in the protected execution path.

Enforce policy before credentials exist

Evaluate identity, tenant boundary, resource ownership, tool allowlist, argument constraints, time and location policy where applicable, rate and spend budgets, data purpose, and current risk signals. Return a structured decision: deny, allow, require approval, require stronger authentication, or require a narrower proposal. Include policy version and machine-readable reason codes.

Credential brokering should happen after allow or approval. Issue a short-lived, audience-bound, least-privilege token where the downstream system supports it, or perform the action through a server-side connector that never exposes the credential to the model. Recheck authorization at execution time; approval does not freeze resource ownership or account status forever.

The official MCP security best-practices guide covers risks including confused-deputy behavior, token passthrough, SSRF, session hijacking, and over-broad scopes. A policy gateway should therefore validate token audience, minimize scopes, constrain outbound destinations, and preserve per-client consent rather than acting as an all-powerful proxy.

Make human approval informed and binding

Approval UI should name the requesting application, acting user, tool, target, material arguments, data disclosed, consequence, and whether the action can be reversed. Avoid showing only the agent's narrative summary; generate the summary from trusted canonical fields and let the user inspect details.

Bind the approval to proposal ID, principal, tenant, tool registry version, canonical argument hash, policy version, permitted execution count, and expiry. Any material argument change invalidates it. A resumed agent may reuse a still-valid approval only for the exact bound operation, and idempotency must prevent that operation from producing a second effect.

Approval fatigue is a security failure mode. Use policy to auto-allow bounded low-risk reads, batch truly identical operations when the user can inspect the set, and require stronger confirmation for irreversible writes. Never reduce prompts by granting broad standing permission without separate governance.

Execute inside capability and network boundaries

Select isolation according to the tool. Code and shell execution may need a disposable filesystem, resource quotas, process limits, no host mounts, and explicit egress. API connectors need destination allowlists, DNS and redirect validation, request size limits, and response caps. Database tools need prepared operations, row and column policy, transaction limits, and read-only credentials unless a write is approved.

Prevent time-of-check to time-of-use drift. Resolve and validate the actual resource immediately before execution, then ensure the operation uses that validated identity. For URLs, check redirects and resolved destinations under the egress policy. For files, use canonical paths and sandbox roots. For cloud resources, bind policy to stable resource identifiers rather than display names.

Give each logical side effect an idempotency key and durable operation record. Retries, workflow resumes, and duplicate workers should produce one business outcome or an explicit reconciliation state. A sandbox contains execution; it does not solve duplicate external actions.

Validate results before returning them to the agent

Tool output is also untrusted. Validate it against a registered output schema where possible, cap size, scan or redact sensitive fields, classify external content, and keep it delimited from system instructions. A web page or document retrieved by a tool can contain prompt injection intended to induce another privileged call.

Record the actual effect separately from the tool's textual claim. For example, store the downstream transaction ID and query authoritative status rather than trusting "payment succeeded" in free text. If execution outcome is ambiguous, route to reconciliation and withhold an invented success or automatic duplicate retry.

Return only the minimum result the agent needs. A user-facing response may cite an audit reference without exposing internal policy reasons, credentials, or sensitive raw provider data.

Build an append-only audit trail

Link proposal, normalized arguments hash, policy inputs, decision, approval, credential grant reference, sandbox configuration, execution attempt, external effect ID, result validation, and user-visible response under one logical operation ID. Keep attempt IDs separate so retries remain visible. Use append-only storage with integrity controls appropriate to the risk; corrections should add events.

Redact secrets at ingestion and restrict access by role. Security investigations may need policy details that product analytics should not see. Define retention by the most sensitive field and support deletion or legal holds without silently breaking aggregate evidence.

Alert on denied high-risk attempts, repeated approval changes, policy bypass paths, unknown tools, unusual egress, scope elevation, idempotency conflicts, and mismatches between reported and authoritative effects.

Diagnose failures with a security root-cause tree

Use branches for proposal integrity, identity and delegation, policy, approval, credential brokerage, isolation, tool behavior, and audit. Proposal failures include schema confusion and canonicalization bypass. Identity failures include cross-tenant context or token audience mismatch. Policy failures include stale catalogs and missing deny rules. Approval failures include payload drift and expired consent.

Isolation failures include host access, unrestricted egress, or shared state leakage. Tool failures include non-idempotent writes, injection in results, and incorrect effect reporting. Audit failures include missing correlations, mutable records, and secret leakage. Each branch should have a trace reason code and a fault test.

When an incident occurs, replay policy from stored normalized inputs without re-executing the tool. Then compare the approved payload with the executed payload, and compare the tool result with authoritative downstream state. This separates a policy defect from an executor or provider defect.

Test controls with isolation experiments

Attempt an unknown tool, extra argument, cross-tenant resource, stale approval, changed payload, expired token, wrong token audience, redirected internal URL, symlink escape, oversized result, prompt injection in tool output, duplicate delivery, worker crash, and policy-service outage. Verify both denial and audit evidence.

Run the same proposal through policy versions in shadow mode to inspect decision changes. Substitute a fake tool to test the gateway without real effects, then test the executor with pre-authorized fixtures to isolate sandbox behavior. Kill the worker after the external service commits but before the result is recorded to verify reconciliation and idempotency.

The OpenAI Agents SDK guardrails documentation distinguishes workflow, input, output, and tool guardrail boundaries. Framework guardrails can add valuable checks, but test the central policy gateway independently so alternate execution paths cannot bypass it.

Assign ownership and choose tradeoffs explicitly

Security owns policy standards, threat models, and exception controls. Identity owns principals, delegation, token audience, and credential brokerage. Tool owners own schemas, side-effect semantics, idempotency, and output contracts. Platform owns gateway reliability, sandboxing, egress, audit, and kill switches. Product owners define consequence and approval experience; release engineering enforces gates.

Stronger isolation and approval increase latency and operational cost. Narrow scopes can require more elevation flows. Rich audits improve investigation but increase sensitive-data handling. The correct choice depends on consequence: a public documentation lookup and a payroll change should not share one control profile.

Gate security properties before rollout

Treat security conditions as non-compensating. Illustrative release policy:

{
  "illustrativeThresholds": true,
  "releaseGate": {
    "maximumPolicyBypassPaths": 0,
    "maximumCrossTenantAuthorizations": 0,
    "maximumApprovalPayloadMismatches": 0,
    "requiredAdversarialScenariosPassing": 20,
    "maximumUncorrelatedSideEffects": 0
  },
  "availability": {
    "highImpactPolicyOutageMode": "fail-closed",
    "ambiguousExecutionMode": "reconciliation-required"
  }
}

These values are illustrative, not universal targets. Canary new tools with constrained tenants and quotas, monitor decision and effect telemetry, and preserve a registry kill switch. No quality or latency gain should waive a proven authorization or isolation failure.

Put the secure path into service

Register tools with trusted risk metadata, accept only typed proposals, enforce policy before brokering credentials, bind meaningful approval to canonical intent, execute with bounded capabilities, validate actual outcomes, and append complete audit evidence. Then attack every boundary with fault and abuse tests.

The architecture is ready when no model text can grant authority, every effect maps to a principal and policy decision, retries cannot multiply intent, and uncertain outcomes stop for reconciliation. Security is achieved at the execution boundary, where proposals become consequences.