Before an AI Agent Gets Production Credentials: An Identity and Containment Checklist

Writing in SecurityBrief, BeyondTrust’s Len Noe makes an argument that lands harder than most agent-security commentary: identity has become the primary attack surface, and enterprises deploying AI agents frequently lack basic visibility into which agents are running, what credentials they hold, and what they did. His framing is that this is a governance failure rather than a tooling failure — organisations grant autonomy without demanding accountability in return. The recommended controls are unglamorous: distinct, attributable identities per agent; comprehensive logging; defined behavioural boundaries; reduced standing privilege; instrumented privileged sessions.

The same theme appears from a different direction in the vendor-governance critique now circulating among CTO advisors — that AI programmes fail because governance is effectively ceded to whichever platform was purchased, and the layers below the demo never get scored.

Both point at the same practical question, and it is one that any enterprise about to move an agent from pilot to production should be able to answer in a single meeting: before this agent holds production credentials, what do we require it to prove?

This post is about the credential and containment layer specifically. The network-level design — segmentation, mutual authentication, explicit verification of every connection — is a separate discipline covered in Zero-Trust Network Architecture for On-Premises AI. What follows sits above it.

The three questions

Everything below reduces to three questions that a security reviewer should be able to answer without reading source code.

Who is it? The agent must authenticate as itself. Not as the user who triggered it, not as the platform, not as a shared automation account. If the answer to “which agent made this call” requires correlating timestamps across three systems, the identity model is not adequate for production.

What can it reach? Scope must be explicit and enumerable: which tools, which systems, which records, which operations on those records. An agent whose reach is defined as “the platform’s integrations” has no meaningful boundary.

Can you stop it? This is the question most often left untested. An agent that cannot be halted mid-workflow, whose credentials cannot be revoked in a known number of minutes, and whose completed actions cannot be enumerated is not contained — regardless of how good the policy document is.

The agent identity lifecycle

Human identity has a well-understood lifecycle: joiner, mover, leaver. Agent identity needs the same rigour and rarely gets it, because agents are created by delivery teams rather than by identity teams.

Two details are worth insisting on. First, delegation must be constraining rather than additive: an agent acting on behalf of a user should never be able to retrieve documents that user cannot see, which is the enforcement problem addressed in Permission-Aware Private RAG. Second, every agent identity needs a named human owner. An agent whose owner has left the organisation is the AI-era equivalent of an orphaned service account, and it will be found during an audit rather than before one.

Standing privilege is the expensive default

The convenient pattern — provision the agent with durable credentials to the systems it needs — is also the one that converts a prompt-handling failure into a live capability. Autonomous agents do not pause, and a loop that would be obvious in a human operator can produce a large number of plausible actions before anyone notices.

The alternative is credentials issued per run and expiring with it: the agent requests authorisation for a specific operation on a specific scope, receives a short-lived credential, and loses it when the run ends. The benefit is not only a shorter exposure window. It also makes the authorisation decision an event that appears in the log, which turns “what was this agent allowed to do on Tuesday” from an archaeology exercise into a query.

Where standing access is genuinely unavoidable — a legacy system with no token-based authentication is the usual case — the compensating controls should be explicit: read-only where possible, rate limits, out-of-band alerting on volume anomalies, and a documented review cycle. The integration patterns for these cases are discussed in Enterprise AI Integration Patterns for Legacy Applications.

Test containment before you need it

Containment is a capability, and capabilities that have never been exercised should not be assumed. A short drill, run before production and repeated periodically, answers the questions an incident will ask.

• Suspend a running workflow. Start a multi-step run, suspend it mid-execution, and record how long the stop took and what state the run was left in.
• Revoke mid-run. Disable the agent’s identity while a run is in flight and confirm that subsequent tool calls fail closed rather than continuing on a cached token.
• Quarantine. Confirm the agent can be removed from scheduling and from user-facing entry points without redeploying the platform.
• Enumerate completed actions. From the audit record alone, list every external action the agent completed in a given window, with enough detail to decide what needs reversal.
• Reverse or compensate. For each action type the agent can perform, know whether it is reversible, requires a compensating transaction, or needs manual correction. Write this down before deployment, not during an incident.
• Reconstruct the run. Rebuild one full execution from logs: initiating identity, agent identity, model and prompt versions, retrieved sources, tool calls with parameters, policy decisions, approvals, and final status. If a field is missing, the trace design is incomplete — the standard set out in AI Decision Receipts for Regulated Enterprise Agents.

The drill produces two useful outputs: a measured containment time you can quote to risk and audit stakeholders, and a list of the actions that cannot be undone. The second list should shape which operations require human approval in the first place.

What cannot be delegated to the vendor

A platform can supply identity primitives, scoping, logging, and stop controls. It cannot decide what an agent in your organisation should be allowed to do, who approves that scope, which actions require a human in the loop, or whether the evidence produced satisfies your regulators. Those remain enterprise decisions, and treating vendor defaults as answers is precisely the pattern the governance critique identifies.

A useful discipline is to score each control layer separately and record who owns it: identity issuance, scope definition, credential lifetime, tool authorisation, execution logging, evidence retention, containment, and incident response. Where the owner is “the platform,” ask what happens if that platform is unavailable, changes its defaults, or is replaced. The layers where an organisation has no independent answer are the layers where governance has quietly moved outside the building. The evaluation criteria in Enterprise AI Agent Security Most Vendors Ignore go deeper on what to ask during selection.

How VDF AI supports this layer

VDF AI runs inside the customer’s own environment, so agent identities, credentials, and audit records stay within the organisation’s security perimeter and identity systems rather than in a vendor tenant. VDF AI Agents enforces per-agent tool allowlists and permission-aware knowledge access, with a per-execution audit record covering inputs, retrieved sources, tool calls, and outcomes. VDF AI Networks carries the execution trace across multi-step workflows, which is what makes both reconstruction and selective suspension practical rather than theoretical.

None of that removes the enterprise’s own work: defining scope, naming owners, approving autonomy levels, and rehearsing containment. It does mean the controls exist to be configured, and the evidence exists to be examined — which is the minimum an agent should have to satisfy before it is handed production credentials.