# AI Agent Security: How Postman's AI Engineer Is Built

# The AI Engineer: Building security into autonomous coding agents

 From the first design doc, security was foremost in Postman's mind when creating our [AI Engineer](https://postman.com/ai-engineer). The safety story lives in the architecture of the agent itself. The AI Engineer is designed so that the riskiest failure modes are blocked by construction, anchored in structural design choices and reinforced by policy, model behavior, and content filtering. This post covers four things: where the real risk lives in an autonomous coding agent, what we have already built to contain it, the hardest open problem in agent security and how we are tackling it in layers, and where we are investing next. ## Where the risk actually lives

 A model that perfectly refuses every unsafe prompt (code comment, configuration file, third-party API response, CI log) still poses risk the moment it acts on text from elsewhere, thanks to prompt injection. The risk lives in the inputs themselves: anyone whose content the agent reads gets a voice in what the agent does. So we treat every input the agent sees as untrusted, including content from sources the user trusts. Second, the agent itself is one untrusted component inside a trusted system, handled the same way any other untrusted input would be. Model alignment and refusals are one part of the defense; the rest lives around the agent. We have seen the same input produce a refusal on one run and a compliant action on the next. Framing matters more than content, and reliance on any single layer is brittle. So we design with the assumption that some prompt injections will land, and we place our controls around the agent, in the surrounding architecture. Third, the impact of prompt injection is not measured by what the agent reads. It is measured by what the agent can do next. A model reasoning over malicious text is, by itself, harmless. The risk materializes only when that reasoning becomes a write across a trust boundary. So the AI Engineer takes a deliberately asymmetric posture: input is open, reads to the context graph are performed within the user's existing authorization, and writes are restricted hard. Inputs are infinite; sinks are finite. That is where the defense budget goes. That is the lens for everything below. ## What we have built

 Each task runs in its own short-lived execution environment. When you submit a task, the AI Engineer spins up a fresh sandbox dedicated to that task and that user. When the task ends, the sandbox is gone. Each task gets its own isolated environment, each user gets their own state, and every sandbox is ephemeral by design. By construction, the blast radius of any single task is that single task. Identity-bearing credentials stay outside the agent's reasoning layer. This is the line from the original announcement, and it does real work. The runner, the process that operates the agent on your behalf, holds your platform credentials. The credentials stay sealed inside the runner, while the sandbox the agent runs in operates as a fully isolated environment. The agent can ask for an action to be performed under your identity, with the credentials themselves staying entirely runner-side. Direct credential theft via prompt injection is structurally excluded from the threat model. What remains is action-side abuse, which the next set of controls is designed for. Outbound traffic is allow-listed and protected against internal probing. Sandbox network egress flows through a dedicated layer that exposes only an explicit set of destinations and gates (loop back, link-local, internal address ranges, and cloud-metadata endpoints). The most direct exfiltration paths, calling arbitrary internal services, hitting metadata, or reaching attacker-controlled hosts on private ranges, are closed by default as a structural property, ahead of any reactive detection. The system prompt is treated as trusted scope and contains no user input; everything else is data. Instruction-shaped files placed in untrusted repositories now sit outside the strongest position inside the model's context. Recent hardening narrowed what counts as the trusted slot and reframed external content as input the agent evaluates rather than commands it must follow. This closes the single highest-leverage injection sink we have seen in this class of system: the place where an attacker controlling a repository could otherwise frame their text as a directive the agent treats as authoritative. Every action the agent takes inherits your permissions, with your access as the ceiling. Commits go to repositories you own. Pull requests open in your name. Workspace changes land where you already had rights. The agent reaches the same surface you would in your own session. A successful injection therefore inherits your permissions ceiling rather than escalating past it. This is the "junior engineer with code review, humans in the loop" framing from the announcement, made concrete: the agent operates with your scope, the same as you would. The reference content the agent draws on is curated and version-controlled. The knowledge base is part of the deployment artifact. It is reviewed, gated, and pinned like any other source we ship. The corpus is fixed at deploy time, and retrieval happens against that known set. One large category of supply-chain-through-RAG (retrieval-augmented generation) attacks, where an attacker poisons a public corpus the agent later retrieves, falls outside the threat surface entirely. ![](https://blog.postman.com/wp-content/uploads/2026/07/Screenshot-2026-07-22-at-3.19.34-PM-1024x540.png)Security posture of your conversation with AI engineer## The hardest open problem: indirect prompt injection

 The class of risk we spend the most time on is the one the rest of the industry is also wrestling with: indirect prompt injection. In summary, an attacker plants instruction-shaped text in a place the agent later reads, such as a file in a repository, a comment in a config, or a response from a tool, and the agent treats that text as authoritative. This is the central unsolved problem in agent security right now industry-wide, well beyond Postman. Any agent that reads attacker-influenceable text and then takes actions on the user's behalf is exposed to some version of it. The field is still converging on best practices, and we think the honest framing is to name it explicitly rather than gesture past it. Our approach is layered and distributed across the architecture, deliberately so. Each layer carries part of the load; the strength comes from how they stack. - Narrowed trusted scope inside the model prevents the strongest framing of an injected instruction.
- Identity-scoped sinks prevent the injection from crossing into systems beyond the user's reach.
- Egress allow-listing prevents exfiltration to attacker-controlled destinations.
- Per-task isolation prevents the injection from persisting beyond the task or contaminating another.
- Separated content-generation passes for cross-boundary artifacts add a refusal opportunity at the point where content actually leaves.
 
 Each layer closes a different leg of an attack. Bypassing one leaves the others standing. If any single layer were sufficient, agent security would already be a solved problem. It remains open, which is why our strategy is defense in depth rather than a single chokepoint. Adversarial review is continuous, baked into each release. New agent capabilities go through internal security testing before they ship. Threat models update with each capability change. Post-release telemetry review feeds back into the next round of hardening. Agent security is continuous work that scales with the capability surface. ## Where we go from here

 The current posture is strong, and the capability surface keeps growing. We treat agent security as ongoing work. Every new capability gets reviewed against the threat model before it ships, every layer of defense is sharpened as we learn from real usage, and the safety surface has to keep pace with the capability surface as both evolve. The direction is set: - Content gating on cross-boundary writes is in place today and will continue to be tightened with more context getting baked in.
- Per-task tool scope is limited today and will continue to narrow as agents get more capabilities.
- Detection alongside prevention is instrumented today and will continue to deepen based on evolving threat actors.
 
 Security investment carries credibility when it lands with results in the field rather than slides on a deck. What we will commit to is the principle: this is continuous work, scaled with the capability surface, and we will keep writing about how it is going. ## Closing

 Secure agents come from architecture. The AI Engineer is built so that the worst outcomes are structurally bounded. Credential theft is excluded by where credentials live, blast radius is bounded by per-task isolation, exfiltration is bounded by where the network can reach, and privilege escalation is bounded by the user's own permissions. The model can be treated as untrusted code, and the system remains safe. That is an evolving posture, and a direction we are committed to. Agent security is iterative work, and the safety surface has to keep pace with the capability surface as both evolve. ## Resources

- [Postman AI Engineer announcement](https://www.postman.com/product/ai-engineer/)
- [OWASP Top 10 for LLM Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/)
- [Simon Willison on prompt injection](https://simonwillison.net/tags/prompt-injection/)
- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
- [Google's guidance on indirect prompt injection](https://security.googleblog.com/2024/06/mitigating-prompt-injection-attacks.html)
- [Postman security practices](https://www.postman.com/trust/)