Treat the agent as an untrusted planner
An infrastructure agent combines a model with tools, data sources, memory, and credentials. Its useful feature—turning natural-language intent into actions—is also why normal chatbot safeguards are insufficient. Direct prompts, retrieved tickets, web pages, logs, and command output can all contain hostile or misleading instructions. The model may also make an ordinary reasoning error. Neither case should become an authorization decision.
Place a deterministic control plane between the model and infrastructure. The model proposes a typed action. An authorization service evaluates caller, agent identity, environment, resource, operation, parameters, change window, risk class, and approval state. A constrained executor then performs only the approved operation. Infrastructure credentials are never placed in the prompt, tool output, long-term memory, or model-accessible environment.
This follows zero trust principles: network location is not enough, and authentication plus authorization occur before resource access. OWASP's agent guidance similarly calls for minimum tool access, per-tool scopes, explicit authorization for sensitive operations, structured outputs, human oversight for high-impact actions, and controls on loops and tool chains.
Give every actor a distinct identity
Keep the human requester, agent workload, policy service, and executor identities separate. Do not run the agent under a shared human administrator account and do not let it impersonate a user without a recorded delegation. Logs must answer who requested the task, which agent and version interpreted it, which policy approved it, and which executor touched the resource.
Use workload identity and short-lived credentials issued just in time for a specific audience and scope. Prefer cloud workload federation, managed identities, service-account tokens with bounded lifetimes, or certificate-based workload identities over stored API keys. Bind credentials to the executor, not the language-model process. Block token export where the platform supports it and rotate or revoke trust relationships through normal identity governance.
Scope identities by environment and function. A production read agent, production change executor, and development automation service should not share a principal. Apply resource-level permissions rather than subscription-wide or cluster-admin roles. NIST SP 800-207A describes identity-tier policy for applications and services in addition to network controls; the same principle keeps an agent's network foothold from becoming universal authority.
Replace generic tools with narrow capabilities
A tool named run_shell_command or call_cloud_api transfers too much policy into a natural-language prompt. Expose task-specific capabilities such as get_vm_status, list_failed_backups, propose_firewall_rule, restart_named_service, or create_snapshot. Define strict JSON schemas, enumerated operations, bounded string lengths, approved regions, resource patterns, timeouts, and maximum result sizes. Reject extra fields and ambiguous values.
Split read, propose, and execute. A diagnostic agent can gather status and produce a change plan without write credentials. A separate executor accepts a signed, policy-approved action object—not free-form model text. For commands that cannot be represented safely, execute predefined scripts identified by immutable version or digest, with validated parameters and a minimal operating-system account.
Constrain network egress from the agent and executor. Permit only required model endpoints, identity services, tool gateways, package mirrors, and target management APIs. Prevent arbitrary callbacks and DNS tunnelling paths. Run code or document-processing components in disposable sandboxes without production mounts or credential sockets.
Classify actions and require independent approval
Create action classes before production. Class 0 is read-only public or low-sensitivity data. Class 1 is authenticated inspection of internal state. Class 2 is reversible, low-blast-radius change such as restarting one stateless development service. Class 3 affects production availability, identity, firewall policy, data, backups, secrets, cost, or external communications. Class 4 is prohibited automation, including disabling audit controls, deleting the last recovery copy, or granting itself broader privilege.
Require a human approval for high-impact actions and ensure approval is independent of agent-supplied claims. The approver sees normalized target, exact operation, parameter diff, expected impact, evidence, pre-checks, rollback, credential scope, and expiry. The agent cannot mark its own proposal approved, select a lower risk class, or change parameters after approval. Bind approval cryptographically or transactionally to the exact action digest.
Use two-person approval for identity-policy changes, destructive data operations, backup deletion, or organization-wide network changes where business risk warrants it. Expire approvals quickly and make them single use. If state changes between plan and execution, fail closed and request a new plan rather than replaying stale authority.
Assume every input can carry instructions
Tickets, runbooks, repository files, monitoring alerts, web pages, and command output are data, even when they contain text that resembles an instruction. Mark provenance and trust level in the context. Separate system policy, requester intent, retrieved evidence, and tool output. Never let retrieved content redefine tool permissions or the approval workflow.
Minimize context. Retrieve only fields needed for the current task, redact secrets and personal information, and cap document size. Treat agent memory as a separate data store with tenant and user isolation, retention limits, write validation, and administrative review. A poisoned note should not become a permanent infrastructure rule.
Validate outputs with schema and policy, not keyword filters alone. Before execution, re-resolve resource identifiers from authoritative inventory, check current state, reject wildcard targets, enforce safe parameter ranges, and run platform-native policy checks. Encode invariants such as never delete the only snapshot, never modify the logging sink from the monitored account, and never restart more than one cluster member at a time.
Make actions observable and stoppable
Generate an immutable correlation ID at request intake and carry it through model decision, retrieval, tool proposal, policy evaluation, approval, credential issuance, API call, and verification. Log normalized parameters and outcome, while redacting tokens, secrets, and sensitive payloads. Send audit records to a destination the agent and executor cannot alter.
Enforce budgets: maximum turns, tool calls, retries, parallel operations, runtime, token spend, and financial cost. Add circuit breakers for repeated failures, expanding target sets, anomalous read volume, denied actions, and unexpected outbound destinations. Operators need a kill switch that revokes credentials, stops executors, and disables tool routes without depending on the agent.
Verification is a separate read from the authoritative target. A successful API response only means the request was accepted. Compare post-state with the intended state, confirm service health, capture the result, and invoke rollback when acceptance criteria fail. The verifier should use read-only credentials and should not rely solely on the model that proposed the change.
Test abuse paths before granting production access
Build an adversarial test suite around the actual tools and data. Include direct and indirect prompt injection, forged approval text in a ticket, secret requests, path traversal, wildcard resource IDs, command injection in parameters, stale approvals, replayed action objects, cross-tenant memory, malicious tool output, recursive delegation, partial API failure, and a target that changes after approval.
Success means the control plane denies or safely contains the attempt and produces usable evidence. Record the model and agent version, tool policy version, identity configuration, test input, expected result, observed result, and residual risk. Re-run tests after model, prompt, tool, memory, retrieval, identity, or provider changes.
Begin with read-only access in a non-production environment. Promote one narrowly defined workflow at a time after test evidence and an owner-approved rollback exercise. If a task cannot be represented as a bounded capability with deterministic authorization and verification, keep it manual.
Implementation checklist
- Separate requester, agent, policy service, executor, and verifier identities.
- Issue short-lived, audience-bound credentials to the executor rather than the model process.
- Replace shell and generic API tools with narrow, typed, resource-scoped capabilities.
- Split read, propose, approve, execute, and verify into distinct stages.
- Classify action risk and prohibit automation for unacceptable operations.
- Bind human approval to the exact normalized action, parameters, target, and expiry.
- Treat retrieved documents and tool output as untrusted data, never as policy.
- Enforce target allowlists, invariants, egress limits, budgets, and circuit breakers outside the model.
- Send correlated, secret-redacted audit records to an agent-inaccessible destination.
- Run adversarial tests and a rollback exercise before each workflow reaches production.