# How to Secure AI Agents in Production > Source: https://ibl.ai/resources/guides/secure-ai-agents-in-production > Last updated: 2026-08-19 *Identity, scoped credentials, sandboxed execution and per-action logging — the controls that bound what a compromised agent can do, since input filtering cannot* Reading time: 14 min read | Difficulty: advanced **On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing — so you can deploy anywhere, from your own cloud to a fully air-gapped network.** ## How do you secure AI Agents in Production? Agent security is a containment problem, not a filtering problem. Language models receive instructions and data through the same channel with no structural boundary between them, so no filter reliably distinguishes a developer instruction from text inside a retrieved document. That means you cannot prevent an agent from being manipulated. You can only bound what a manipulated agent is able to do. Everything in this guide follows from that: give each agent its own identity, grant narrow and short-lived authority, sandbox execution, require confirmation before consequential actions, and log every action against an identity so an attempt is detectable rather than invisible. ## Prerequisites - **An identity provider that can issue scoped credentials:** Agents become principals with short-lived, task-scoped grants. Most organizations extend what they already have rather than building an agent-specific credential store. - **An inventory of agent capabilities:** Every tool, system and dataset each agent can reach. Capabilities accrete faster than anyone re-scopes credentials, so this needs to be current rather than original. - **Somewhere to write an immutable audit trail:** Storage you control, with retention set by your obligations. An audit trail inside a vendor's platform is a reporting view, not evidence you hold. - **Agreement on which actions are irreversible:** Sending, publishing, deleting, paying and granting access. This list is what determines where human confirmation is mandatory. ## Step 1: Give every agent its own identity Not a shared service account and never a borrowed human session. An agent inheriting a person's credential produces a log that positively misattributes machine actions to that person, which is worse than no log. - [ ] Register each agent as a distinct principal - [ ] Remove shared service accounts used by multiple agents - [ ] Never let an agent authenticate as the delegating human - [ ] Integrate with the existing directory so delegation ties to real people ## Step 2: Replace standing keys with short-lived scoped grants A static API key must cover the broadest thing the agent might ever do, which makes it over-privileged on every other day. Authority should be requested per task and expire. - [ ] Issue credentials scoped to the specific task and dataset - [ ] Set expiry to the expected task duration - [ ] Eliminate keys with no expiry — These are the highest-value target in the environment. - [ ] Ensure revoking one agent does not break the others ## Step 3: Sandbox execution and constrain the tool surface Agents that execute code or call tools should do so in an isolated environment with an explicit allowlist, network egress controls and resource limits. - [ ] Run code execution in an isolated sandbox per task - [ ] Allowlist tools per agent rather than exposing a shared catalogue - [ ] Restrict network egress from the sandbox - [ ] Set CPU, memory and wall-clock limits ## Step 4: Require human confirmation on irreversible actions This is the control that stops a successful prompt injection from completing the damage. Reading is recoverable; sending, publishing, deleting and paying are not. - [ ] Enumerate irreversible actions explicitly - [ ] Require confirmation from the delegating human, not any human - [ ] Show what will happen in terms a reviewer can evaluate — A confirmation nobody understands is a rubber stamp. - [ ] Log the confirmation alongside the action ## Step 5: Defend against prompt injection in depth, expecting it to be imperfect Input filtering and instruction hierarchies raise the cost of an attack but cannot close the class, because the space of natural-language phrasings that convey an instruction is unbounded. - [ ] Treat all retrieved content as untrusted, including internal documents - [ ] Separate instruction and data channels as far as the model allows - [ ] Apply filtering as a cost-raising layer, not as the control - [ ] Test with adversarial content as part of release — Including indirect injection planted in retrievable sources. **Tips:** - Assume every input-layer defense will eventually be bypassed and check that the permission scope alone still makes the outcome acceptable. ## Step 6: Log every action against an identity, at write time Delegation cannot be reconstructed after the fact, so the record must be complete when it is written. This is what turns a successful attack from invisible into detectable. - [ ] Record agent identity, delegating human, scope, model, version and timestamp - [ ] Include the business context — matter, case, account or ticket - [ ] Write to storage inside your perimeter - [ ] Alert on scope-boundary violations rather than only on errors ## Common Mistakes ### Letting agents inherit human credentials **Consequence:** The agent gains everything the person can do, and the audit log misattributes machine actions to that person. **Prevention:** Make each agent its own principal with delegation recorded explicitly, never a borrowed session. ### Relying on prompt-injection filtering as the control **Consequence:** The first bypass produces an incident whose blast radius equals the agent's full permission set. **Prevention:** Treat filtering as a cost-raising layer and verify that permission scope alone makes the worst case acceptable. ### Granting environment-scoped rather than task-scoped access **Consequence:** An agent provisioned for the broadest possible task holds that access permanently, including during a compromise. **Prevention:** Issue short-lived credentials scoped to the current task and dataset, expiring when the task ends. ### Logging outcomes without delegation **Consequence:** The record shows what happened but not who caused it or under what authority, which fails the attribution standard auditors apply. **Prevention:** Capture agent, delegating human, scope and business context at write time — none of it can be reconstructed later. ## FAQ **Q: Can prompt injection be prevented?** Not reliably. Instructions and data share one channel with no structural separation, and no classifier covers the unbounded space of natural language. Defense is containment: scope narrowly, confirm irreversible actions, and log everything. **Q: What is the single most effective agent security control?** Short-lived, task-scoped credentials. They bound what a compromised or manipulated agent can reach, which is the only property that holds when input-layer defenses fail. **Q: How is agent identity different from service-account access?** A service account is shared, permanent and broadly scoped, so it defeats least privilege, attribution and granular revocation at once. Agent identity makes each agent a distinct principal with per-task authority and a delegation record. **Q: Should agents be allowed to execute code?** Often yes, and it is one of the most valuable capabilities — but only inside a per-task sandbox with an allowlisted tool surface, restricted egress and resource limits, so the worst case is a contained failure. **Q: Does self-hosting improve agent security?** It does not change the attack surface, but it changes what you can do about it. Holding the source lets your team inspect and modify the permission model and guardrails, and the audit trail that detects an attempt is an artifact you own. ## Can you do this on infrastructure you own? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.