Notifications
Clear all
Topic starter
02/08/2026 12:05 pm
TL;DR: Safe agent behaviour depends on infrastructure controls like network isolation, short-lived credentials, scoped context, and failure containment, not prompt instructions, according to Cogent’s production experience running AI agents against 11.47 million vulnerabilities. That means enterprise teams must treat agent security as a runtime governance problem, not a prompt-tuning exercise.
NHIMG editorial — based on content published by Cogent: Blog Engineering, What We Learned Building Safe Agents for Enterprise Security
By the numbers:
- 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.
Questions worth separating out
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.
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.
Q: What breaks when agent safety depends on prompt instructions?
A: Prompt instructions fail as a control because they are not enforceable.
Practitioner guidance
- 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.
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
👉 Read Cogent's blog on building safe enterprise agents in production →
Enterprise AI agents: what keeps them safe in production?
Explore further
02/08/2026 1:10 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Safe enterprise agents depend on infrastructure, not prompts
