Safe enterprise agents depend on infrastructure, not prompts

At a glance

What this is: This is a practical analysis of how enterprise AI agents were hardened in production and the main finding is that safety comes from infrastructure boundaries, not prompt-based rules.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern agents that query production systems, hold credentials, and act across tenants without creating uncontrolled blast radius.

By the numbers:

• 27 days
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.

👉 Read Cogent's blog on building safe enterprise agents in production

Context

Enterprise AI agents are becoming operational actors, not just chat interfaces. They query databases, call tools, and generate actions that can affect production systems, which means the control problem shifts from model quality to runtime identity governance, credential boundaries, and containment.

The core lesson in this article is that prompt instructions are not a security boundary. For AI agent identity, the practical question is whether the environment enforces least privilege, tenant isolation, and tool-level guardrails strongly enough that a bad decision cannot become a platform-wide failure.

For IAM and NHI programmes, this is the same governance pattern seen across service accounts, API keys, and workload identities: access must be scoped to the task, the tenant, and the execution window. The article’s starting position is typical for mature teams because it replaces trust in instructions with enforced controls.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents create a larger blast radius than traditional automation?

A: AI agents can chain tools, reuse context, and expand their effective reach during execution, which means one over-permissioned identity can affect multiple systems quickly. Traditional automation is usually narrower and more deterministic. The practical response is to limit each agent’s scope and validate its behaviour continuously.

Q: What breaks when agent safety depends on prompt instructions?

A: Prompt instructions fail as a control because they are not enforceable. A model can ignore, misread, or be manipulated by external input, so the real control must be in the sandbox, network layer, and identity policy that govern execution.

Q: How do security teams know if AI environment isolation is actually working?

A: Isolation is working only if the AI system cannot reach external networks, shared credentials, or higher-privilege infrastructure paths without an explicit control failure. Teams should test not just whether the obvious route is blocked, but whether proxies, package services, and internal bridges can still be abused.

Technical breakdown

Why prompt-based safety fails for AI agents

Prompt-based safety depends on the model remembering instructions, but agent execution is shaped by the surrounding environment. If an agent can reach arbitrary domains, follow redirects, or call unapproved services, then the prompt is advisory rather than authoritative. In practice, the trust boundary must sit outside the model and inside the runtime, where network policy, tool allow-lists, and execution boundaries can actually block unsafe actions. This is the difference between asking for compliance and enforcing it.

Practical implication: move safety controls into the sandbox, network layer, and tool broker rather than relying on prompt text.

How short-lived credentials change agent identity risk

AI agents need credentials to act, but those credentials should be injected into the execution environment, not embedded in prompts or tool arguments. Short-lived tokens reduce exposure if logs, traces, or model outputs are compromised, and they also force rotation to happen independently of the agent’s reasoning loop. That matters because agent identity is still NHI identity, even when the workload is powered by a model. The key issue is not whether the agent can use a secret, but whether the secret has a narrow lifetime and scope.

Practical implication: issue tenant-scoped, short-lived credentials through the runtime and keep them out of prompts, tickets, and traces.

Why scoped context is safer than full data access

Agents do not become safer when they are given all available context. Wider context increases the chance of accidental oversharing, cross-tenant leakage, and attention dilution, especially when the agent is evaluating many records at once. Scoped context means the agent sees only the tenant, tables, and time window required for the task, while aggregated reporting uses pre-computed views instead of raw data. This is a least-context pattern, and it is one of the clearest ways to reduce blast radius in multi-tenant environments.

Practical implication: design context filters and storage boundaries so the agent cannot see data it does not need.

Threat narrative

Attacker objective: The objective is to turn a trusted enterprise agent into a path for data exposure, tenant crossover, or destructive operational action.

1. Entry occurs through a high-privilege agent workflow that is allowed to query production data and call multiple tools in order to complete remediation tasks.
2. Escalation happens when broad context, weak network boundaries, or prompt-injected instructions let the agent reach unapproved services or mix tenant data.
3. Impact is created when the agent leaks sensitive credentials, queries the wrong tenant, or generates unsafe remediation actions that affect production systems.

Breaches seen in the wild

• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Infrastructure, not prompts, is the real control plane for enterprise AI agents. The article shows that safety breaks when teams trust model instructions instead of enforcing runtime boundaries. Network allow-lists, tenant scoping, and tool isolation are the actual governance mechanisms because they constrain action regardless of what the model wants to do. Practitioners should treat prompt safety as documentation, not control.

Least-context access is the agent-era version of least privilege. Giving an agent every asset, vulnerability, and tenant record makes the blast radius larger than the task requires. The named concept here is context blast radius: the amount of unnecessary data an agent can see or combine during execution, which directly increases leakage and misclassification risk. Security teams should recognise that over-broad context is itself an identity control failure.

Short-lived credential injection is the only defensible pattern for non-human execution. The article’s approach confirms that secrets belong in the runtime environment, not in prompts, tickets, or logs. That matters because model interaction surfaces are observability surfaces, and anything placed there can be echoed, stored, or replayed. IAM and PAM teams should treat agent credentials as ephemeral execution tokens, not durable identity artefacts.

Failure containment defines whether an agent is enterprise-ready. A bad tool call, timeout, or sandbox crash must remain local to the session. If one failure can poison the broader workflow, then the organisation has built automation, not governed autonomy. The practical conclusion is that agent security must be evaluated as an isolation architecture, not a feature checklist.

Multi-tenancy for agents has to be physical before it can be procedural. Storage-level separation, dedicated database paths, and tenant-specific credentials are what prevent one query mistake from becoming a cross-customer incident. Logical filters alone are too fragile once agents are operating at machine speed. The implication for practitioners is clear: shared-state designs are not acceptable for high-stakes enterprise agents.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
• A separate finding shows that systems with least-privileged AI access had a 17% incident rate compared with 76% for over-privileged systems, according to the same survey.
• For a broader governance lens, see OWASP NHI Top 10 for the control patterns that most directly constrain agentic risk.

What this signals

Context blast radius: the next wave of agent governance will be defined by how much data and how many tools a session can touch, not by how fluent the model sounds. Teams that still measure AI safety at the prompt layer will miss the actual control surface, which is the runtime environment and its privilege boundaries.

With 70% of organisations granting AI systems more access than human employees in the same role, the governance gap is already structural rather than experimental. That makes agent identity a policy and architecture issue, not a model-selection issue, and it pushes IAM teams toward least-context design, ephemeral credentials, and stricter tenant isolation.

This also changes how security leaders should think about observability. Logging more agent activity is useful only if the runtime is already constrained, because visibility without enforcement just produces better evidence of excessive access.

For practitioners

• Enforce runtime network boundaries for every agent workload Use default-deny egress with explicit allow-lists for approved domains, and log every denied outbound attempt so policy drift is visible during review.
• Inject short-lived credentials only through the execution environment Issue tenant-scoped STS-style tokens or equivalent ephemeral secrets at runtime, and keep them out of prompts, tool arguments, and trace payloads.
• Scope each agent to one tenant and one task window Limit databases, tables, and objects to the minimum set required for the session, and prefer aggregate data products when cross-tenant analysis is needed.
• Separate tool failures from session failure Design sandbox crashes, malformed tool responses, and timeouts so they do not terminate the parent workflow or contaminate later tool calls.
• Test agent boundaries with adversarial scenarios Run red-team cases that attempt credential leakage, tenant crossover, blocked-domain access, and unsafe tool chaining before you expand production access.

Key takeaways

• Enterprise AI agents become governable only when the runtime enforces boundaries that prompts cannot override.
• Short-lived credentials, scoped context, and tenant isolation are the controls that prevent agent mistakes from becoming platform incidents.
• The real test is whether one bad tool call stays local, because failure containment is now an identity requirement.

Key terms

• Integration Blast Radius: Integration blast radius is the amount of downstream access and data exposure a compromised connection can create. It is determined by scopes, tenant reach, and connected systems, so it is a governance measure as much as a technical one.
• Runtime boundary: The point at which an identity's permissions, execution context, and observable behaviour are contained for policy purposes. In agentic systems, runtime boundaries matter because they determine whether the organisation can explain, audit, and limit what the agent did after execution begins.
• Ephemeral Agent Identity: An AI agent identity that exists only for the duration of a specific task or session and is automatically destroyed upon completion. Ephemeral identities are the gold standard for agentic security — they eliminate persistent credential theft risk.
• Failure Containment: A design pattern where a tool error, sandbox crash, or malformed response stays local to the current session. For agents, this is essential because a single failure should not corrupt later actions, leak data across tenants, or terminate the broader workflow.

What's in the full article

Cogent's full blog covers the operational detail this post intentionally leaves for the source:

• Concrete sandbox configuration patterns for isolated execution and failure containment
• Code-level examples for injecting AWS STS credentials through environment variables
• Implementation detail for tenant-specific databases, Redis instances, and S3 separation
• The article's own testing approach for boundary validation and adversarial agent behaviour

👉 Cogent's full post covers sandbox design, credential injection, and tenant-isolation patterns in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.