Most enterprise agent programs don't stall because the models aren't good enough. They stall in a meeting.
An engineering team builds something genuinely useful, an agent that can pull from a data warehouse, file a ticket, draft a customer response, and kick off a job. Then it goes to review, and someone in security or privacy asks the obvious question: what exactly can this thing reach, and what happens when it's wrong? Nobody has a crisp answer. The pilot gets parked. Six months later the company is still "exploring agents."
We recently worked through this with a CTO who also holds the Data Protection Officer role at a customer of ours, a combination that turns out to be clarifying. Rather than asking whether agents were safe in the abstract, she wrote down eight principles that any agent would have to satisfy before it got real access to real systems. Then she asked us to show, principle by principle, what her team could enforce today and where the ground was still moving.
That exercise is the most useful artifact we've seen for getting an agent program unstuck, because it converts an unanswerable question ("are agents secure?") into eight answerable ones. Here they are, with what we'd suggest doing about each.
The principle: an agent gets only the permissions its task requires, and nothing more.
Start with the boundary almost nobody sets: network egress. An agent should be able to reach the models and tools exposed through its AI system's API, and nothing else. Every other outbound path from the agent's environment should be closed. This is the control that determines whether "least privilege" is a real constraint or a description of your intentions, because an agent with open internet access has whatever privileges it can talk its way into. Agents built in Agent Forge, our no-code agent builder, are configured this way out of the box. If you're writing custom agents outside it, sandbox them yourself, or wait for the Prediction Guard sandboxes shipping soon and deploy them there.
Do this now: issue API keys per application, per user, or per integration, never one shared standing key, and make every one independently revocable. Scope MCP access at both levels available to you: an admin connects a specific MCP server, then chooses which functions within that server are enabled. Enable only the functions an agent actually needs, not the whole server because it was easier. Use Agent Forge's workspace separation, and leave public, cross-workspace, and org-wide sharing off until you have a specific reason to open one of them.
The failure mode here is boring and universal. One key gets created during a proof of concept, it works, and eighteen months later six integrations and four agents run through it. Nobody can revoke it without breaking something, so nobody does.
Where this is going: least privilege gets stronger when it's a per-agent policy set centrally rather than a key someone remembered to scope correctly. Agent registration with per-agent policy enforcement is the direction we're building, along with finer-grained runtime policy on individual MCP functions.
The principle: credentials should be narrow, short-lived, and torn down when the task ends.
The instinct is to treat this as unsolvable and move on. It isn't. The specific thing to stop doing is authenticating agents with static, long-lived API keys when a better option is already available.
Do this now: where you must use keys, give every one an expiry and a quota. There is no good reason for an unlimited, never-expiring key to exist in your deployment, and "we'll rotate it later" is how permanent credentials get created. Then get off static keys where you can: MCP registration supports OAuth 2.1, so tool access can run on per-user, non-shared, short-lived logins instead of a shared secret. Turn that on wherever the server supports it. That single change moves you from "a credential exists indefinitely" to "a credential exists for a session," which is most of what this principle is asking for.
Where this is going: two gaps remain, and they're worth naming to your security team rather than papering over. The first is automated rotation: programmatic key rotation tied to Kubernetes secrets or a cloud secrets manager, with expiry alerting, is a requested capability on our side and not yet dated. The second is ephemeral computation. Binding an agent's identity to a contained microVM that comes up for a task and goes away after, with its context and files persisted to an object store tied to that identity, is what makes access genuinely session-scoped rather than merely short-lived. Alongside that, we're building system agents that watch for out-of-bounds behavior and can quarantine an agent and its API keys at machine speed, because the honest answer to "what if a short-lived credential is abused inside its window?" is that a human review cycle is too slow.
The principle: anything destructive, irreversible, or expensive requires human approval first.
Notice this is a statement about actions, not about models. No amount of model quality makes an irreversible action safe to take unsupervised, and no amount of model weakness makes a read-only query dangerous. Sort your agent's capabilities by consequence, not by confidence.
Do this now: use per-function approval gates rather than treating approval as an all-or-nothing setting. Agent Forge lets you require human approval, "ask" mode, before a tool runs, and you can set it across every tool or on individual functions within an MCP server depending on how much damage each one can do. That granularity is what makes the control survivable in practice: blanket approval on everything trains people to click through, while approval on the three functions that actually delete, spend, or deploy keeps the gate meaningful. Run your governance policies in block mode, not just log-event mode, once you've tuned them, because a policy that only records violations is a research instrument rather than a control. And keep genuinely destructive operations out of the connected toolset entirely until a review gate exists for them.
Where this is going: the frontier is what happens after something goes wrong, and how fast. Circuit breakers to quarantine a failing or problematic component, playbooks for automated remediation, system agents that escalate suspicious agent behavior to human reviewers rather than waiting for someone to check a dashboard, and configurable autonomy so you decide how much the governance layer may fix on its own before it involves a person.
The principle: secrets and PII stay out of the agent's reach unless the task genuinely requires them.
The useful framing here is least agency, not just least privilege. Privilege is what an agent is allowed to touch. Agency is how much it can set in motion. Limiting both is what keeps blast radius small, and it's the difference between a prompt injection attempt that becomes a footnote and one that becomes an incident. An agent tricked into exfiltrating data it never had access to is a nuisance. An agent tricked into exfiltrating your customer database is a breach.
Do this now: enforce PII masking at the organization level, not per agent, because a per-agent setting is a per-agent opportunity to forget. Masking should happen before data leaves your premises or reaches any external model, and it should cover every interaction, including the ones your non-developers build in Agent Forge. Keep secrets out of human hands as well: entered once, stored in a real secrets manager, obfuscated in Agent Forge so the person wiring up an agent never sees the value. Then be disciplined about scope, because every sensitive source you connect "just in case" is permanent risk bought with hypothetical value.
Where this is going: more of this moves into runtime governance. Modules that detect system prompt leakage, and system agents that watch an agent's context and files for code execution aimed at extracting sensitive data, catch the cases that static scoping can't anticipate. Further out, "sensitive" stops being a vendor's category: guardrails built from your own private documents let you define it in your organization's actual terms.
The principle: log what the agent accessed and what it did, so a human can reconstruct it afterward.
Auditability pays for itself faster than anything else on this list, because it's what lets you say yes to the next agent. Without a record, every incident is a mystery and every review starts from zero.
Do this now: insist on an immutable audit log of governance and security events. Then check the part most teams forget, which is whether changes to the system itself are audited: a model configuration change or a governance policy module change should be recorded and visible to admins, because a policy someone quietly loosened is indistinguishable from a policy that never worked. And stream the log somewhere your security team already looks, CloudWatch, your SIEM, whatever you actually watch. A log sitting inside the AI platform is evidence nobody reads. Wire it up now, while the volume is small and the integration is easy.
Where this is going: three things deepen this. A fully local control plane UI, sovereign and private like the rest of the deployment, with real visualization of security events, aggregated statistics, and ordinary usage data rather than raw log lines. Agent tracing that stitches actions together by agent identity across models, tools, sessions, and threads, which is what you need to investigate a custom agent's behavior instead of guessing at it. And fleet-wide behavior statistics, because once you're running a digital workforce of agents, reviewing them one at a time stops working. You need to see drift, outliers, and the agent that started doing something new last Tuesday.
The principle: allowlist what the agent can reach. Deny by default. When in doubt, choose the safer option.
The difference between an allowlist and a blocklist is the difference between failing safe and failing open. Most AI content controls today are blocklist-style: you enumerate what to block, and anything you didn't think of gets through. Fine as one layer. Not a boundary.
Do this now: the real boundary is the one from principle 1, restricting the agent's environment to the models and tools reachable through its system API and closing everything else. Inside that, apply granular allow, ask, or deny per function within each MCP server, and keep the rule that nothing is reachable unless a system admin connected it, or explicitly permitted users to register their own servers. Enforce it at the gateway where the agent actually reaches the tool, not only in the agent's own configuration, since an agent's config is a suggestion and a gateway is a control. Apply a governance baseline drawn from an established standard such as the NIST AI Risk Management Framework so you're tuning a deny-by-default posture rather than inventing one. Layer topic filtering on top, clear-eyed that it's a blocklist and therefore incomplete.
Where this is going: a built-in MCP proxy that centralizes monitoring, governance, authentication, and control for every MCP server integration, following OWASP's practical guide for secure MCP server development, plus MCP-specific runtime governance and, further out, boundaries defined once across the whole fleet instead of re-specified per agent.
The principle: run agents in contained environments so a mistake cannot spread.
If you want a reason to take this one seriously, the July 2026 intrusion at Hugging Face is the case study. An autonomous agent running inside an evaluation sandbox found a way out of it, reached the public internet, obtained remote code execution on production infrastructure through a dataset processing path, and then moved laterally because those processing workers were not sufficiently isolated from internal systems. Two containment layers failed in sequence. We walked through what it changes for enterprises deploying agents of their own in our field report on the incident, which you can download here.
There are three layers to get right, and they're often collapsed into one.
Do this now: start with where the platform runs, because that's the layer you can't retrofit. Our control plane runs entirely inside your own infrastructure, outbound-only: the cluster pulls its configuration, and we have no inbound access and no remote control. Governance, supply chain management, and observability all operate inside your boundary, so adopting an AI platform doesn't mean granting a vendor network access. Second, where the builder runs. Agent Forge is network-isolated and single-tenant, operating on top of the control plane's API and governance infrastructure, with that isolation enforced both within your boundary and within the Kubernetes cluster it runs in. Third, where each agent runs, which today means your existing Kubernetes and cloud controls: namespace isolation, security groups, private subnets.
Where this is going: that third layer becomes per-agent rather than per-cluster. We're building orchestration of microVM sandboxes for agents and for code execution, both inside Agent Forge and through the API, plus sandbox scanning and the ability to roll an agent's state back to a context snapshot so a bad state can be reversed instead of propagated. Isolation stops being a property of your network and becomes a property of each agent.
The principle: authenticate the agent itself, and stay suspicious of instructions and data arriving from untrusted sources.
This is where teams thinking about single agents diverge from teams thinking about agent systems. As soon as one agent delegates to another, "who is asking, and on whose authority?" becomes a question your infrastructure has to answer rather than one your architecture diagram assumes away.
Do this now: treat provenance as an input-validation problem and enforce it in runtime governance, not in prompt wording. Two modules matter. Prompt injection detection screens for adversarial instructions in what an agent processes. Grounding verification does the less obvious half: it flags model inputs that arrive without appropriate trusted context from a knowledge base or tool. That case deserves to be treated as a security event, not a quality problem, because an agent reasoning from unsourced content is an agent whose inputs you cannot account for. On identity, use OAuth 2.1 for MCP authentication and tie tool access to an authenticated per-user login rather than a shared credential. And keep anything pulled from external or untrusted sources segregated from high-privilege agents, which is principles 4 and 6 doing the work.
Where this is going: verifiable agent identity, through agent registration and identity bound to the hardware and execution environment an agent actually runs in. System agents monitoring behavior, context, and files for signs an agent is operating outside its scope. Permissions and audit trails that travel intact when an agent hands off across deployments. And cross-agent trust verification, so one agent can't silently inherit another's privileges. Multi-agent workflows without provenance verification are a privilege escalation surface waiting to be found.
Read these eight together and a pattern shows up. Most of what matters is enforceable today, and it's more than teams assume: network egress restriction, per-function MCP scoping, per-user OAuth authentication, per-function human approval gates, organization-level PII masking, immutable audit logging including configuration changes, an allowlist enforced at a gateway, an agent builder running single-tenant and network-isolated inside your own boundary, and prompt injection and grounding checks in runtime governance. That's a defensible agent program, and none of it requires waiting.
What's genuinely still maturing is a shorter list: fully automated credential rotation, per-agent microVM sandboxing, machine-speed autonomous response, and cross-agent trust verification for multi-agent workflows.
The wrong conclusion is to wait for the second list. The right one is to be specific about which list each control sits on, put compensating controls around the gaps, and write it down. Every agent program we've seen move fast has done exactly that. Every one that's stuck is still arguing about whether agents are safe in general.
Pick your eight. Answer them honestly. Then ship the first agent.
Prediction Guard runs entirely inside your infrastructure, outbound-only, with no inbound vendor access, applying PII masking, prompt injection and grounding checks, immutable audit logging, and per-function MCP policy enforcement to every interaction. If you're working through a checklist like this one, we'd like to see it. Get in touch.