An AI agent becomes a security system the moment it can do more than generate text. File access, shell commands, browser sessions, databases, internal APIs, memory, and credentials turn a probabilistic model into an actor inside your environment.
The central rule is simple: the model may propose an action, but it must not be the authority that decides whether the action is permitted.
Figure: A repository-controlled symbolic link can redirect an apparently local edit into a sensitive host file when canonical-path policy is missing. Source: Wiz Research.
The OWASP Agentic Security Initiative treats autonomous workflows as a distinct security surface. Production design should therefore start with capabilities and trust boundaries, not with prompt wording.
Draw the capability map first
List every resource the agent can read, modify, execute, or transmit. Include indirect capabilities such as a browser profile that already contains authenticated sessions.
| Capability | Primary risk | Default production posture |
|---|---|---|
| Read repository | Prompt injection, secret discovery | Isolated copy, secret scan, no home mount |
| Write files | Persistence, path traversal | Workspace-only canonical paths |
| Execute commands | Code execution, lateral movement | Allowlisted commands in a sandbox |
| Call APIs | Unauthorized actions | Scoped service identity and policy checks |
| Access network | Exfiltration, remote payloads | Destination allowlist and egress logging |
| Use memory | Cross-user leakage, poisoned state | Tenant isolation, provenance, retention limits |
| Ask for approval | Misleading or fatigued users | Resolved action, risk context, bounded scope |
If a capability has no owner, policy, audit event, and revocation path, it is not ready for autonomous use.
Treat all context as untrusted
Agents mix instructions with data. A README, support ticket, retrieved document, webpage, tool response, or database row may influence the model’s next action. None of those sources should be trusted merely because the model describes them as relevant.
Prompt injection cannot be solved by another instruction that says “ignore malicious instructions.” The defensive control must exist outside the context window.
Use provenance labels for context and tools. The policy layer should know whether a value came from the user, an approved system configuration, a retrieved public page, or a previous model output. High-risk actions should reject arguments derived only from untrusted sources or require an independent confirmation path.
Put a deterministic gateway before every tool
Each tool call should pass through a gateway that validates:
- The calling agent and tenant identity.
- The exact tool and operation.
- Canonical resource identifiers and resolved file paths.
- Argument schema, size, and allowed value ranges.
- Data classification and destination policy.
- Rate, cost, and time limits.
- Whether human escalation is required.
The gateway should return a structured allow, deny, or escalate decision. Do not let free-form model text become a policy decision.
The GhostApproval disclosure demonstrates why canonical paths matter. A repository-relative filename can resolve through a symbolic link to a sensitive location outside the workspace. An approval UI that shows the unresolved name does not describe the real action. Read our GhostApproval and Friendly Fire security brief for the attack details and vendor responses.
Isolate execution from developer state
Figure: Deterministic policy, scoped tools, isolated execution, and external audit controls bound what an agent can affect. Yield Signal Daily editorial diagram.
Run untrusted or third-party work in a disposable environment. The sandbox should begin without:
- A mounted developer home directory.
- SSH agent sockets or browser profiles.
- Package-publishing, cloud, or production credentials.
- Broad source-control tokens.
- Unrestricted access to internal networks.
Provide narrowly scoped credentials just in time, and revoke them when the task ends. Prefer workload identities over copied long-lived secrets.
Filesystem controls should be enforced at the operating-system or runtime boundary. A string check before execution is insufficient if links, mount points, race conditions, or generated files can change the resolved destination.
Separate read, propose, and act
One agent session does not need every permission at every stage.
Read stage
Inspect the task and build an inventory without execution rights. Extract requested operations, suspicious files, external dependencies, and required data.
Proposal stage
Generate a plan and structured tool arguments. The output remains untrusted and has no side effects.
Action stage
Execute approved operations in a fresh, narrower context. Apply deterministic policy again at the moment of use.
This separation limits the damage from context manipulation and makes logs easier to interpret.
Design human approval as a security control
Approval is useful only when the user sees the effective action.
A good prompt includes:
- The canonical file path or API resource.
- The exact command or structured operation.
- The identity and permissions that will be used.
- The destination for any transmitted data.
- Why the action is outside normal policy.
- Whether approval applies once or creates a reusable rule.
Avoid repeated low-value prompts. They train users to approve mechanically. Routine safe actions belong in a narrow allowlist; unusual high-impact actions deserve a precise escalation.
Control memory and retrieval
Figure: Disposable infrastructure, zero-secret startup, path checks, process restrictions, egress policy, and audit logs limit a wrong model decision. Yield Signal Daily editorial diagram.
Long-term memory creates a second trust boundary. Store tenant, user, source, timestamp, and confidence metadata with every memory item. Prevent one user’s context from appearing in another user’s session.
Retrieved documents should remain data, not system instructions. Sanitize active content, limit document size, and preserve source provenance through the final tool decision.
Provide deletion and retention controls. A memory system that cannot explain or remove stored information creates operational and privacy risk even when the model behaves correctly.
Log what happened below the chat layer
Conversation transcripts are not sufficient for incident response. Record:
- Model and policy versions.
- Context source identifiers.
- Proposed and authorized tool calls.
- Canonical file paths and API resources.
- Child processes, network destinations, and data volume.
- Human approval identity and scope.
- Result, failure, rollback, and revocation events.
Protect logs from the agent itself and avoid storing unnecessary secret values. The goal is a reconstructable action trail, not a second unbounded data lake.
Figure: Useful audit telemetry records identity, provenance, canonical targets, policy decisions, effects, and rollback state below the conversation layer. Yield Signal Daily editorial diagram.
Test failure modes before autonomy
Red-team the complete system, not only the model. Include malicious repositories, poisoned retrieval content, deceptive tool output, symlink paths, oversized arguments, stale approvals, cross-tenant memory probes, credential exfiltration, and unavailable dependencies.
Verify that denial is safe. An agent that loops indefinitely, retries an expensive call, or falls back to a broader credential after rejection is not failing closed.
Use staged autonomy:
- Read-only observation.
- Proposed actions with mandatory approval.
- Auto-execution for a narrow low-risk allowlist.
- Broader action only after measured reliability and incident readiness.
Minimum deployment gate
Do not enable autonomous production actions until all of the following are true:
- Capabilities and data flows are inventoried.
- Untrusted context is labeled and isolated from policy.
- Tool arguments are schema validated.
- Paths and resource identifiers are resolved before authorization.
- Identities are tenant-scoped and least privilege.
- Execution is sandboxed and egress controlled.
- High-impact actions have precise approval or dual control.
- Memory has provenance, isolation, retention, and deletion.
- Action-level logs and emergency revocation are tested.
- The system has a safe fallback when the model, tool, or policy service fails.
Security is not a property of the prompt. It is the combined result of identity, policy, isolation, observability, and recovery around a model that should always be treated as fallible.
