What should organisations do first before putting agents into production?

Start by inventorying which systems the agents can reach, then remove any standing access that is not tied to a specific task or policy condition. Production rollout should wait until access is scoped, logged, and revocable at runtime.

What to inventory before an agent goes live

The first control decision is not whether the agent is “intelligent”, it is what it can actually reach. Inventory every system, API, data store, admin surface, and external connector the agent may touch, then classify each by business criticality and blast radius. If you cannot name the reachable assets, you cannot scope the agent’s authority or judge whether production access is safe.

That inventory should distinguish direct actions from indirect ones. An agent may only need read access for one workflow, but a tool, token, or delegated session can quietly expand that into write, delete, or approve actions elsewhere. This is why agent architecture and access design need to be reviewed together, not as separate rollout tasks.

Inventory also needs an owner for each reachable system. In practice, rollout breaks when no one can answer who approved the connection, who can revoke it, and which team can validate that the agent is still operating within its intended task boundary. A complete asset map is the prerequisite for every later access decision.

Why standing access is the wrong default for production agents

Standing access creates an always-available path from the agent into production systems, which means any prompt failure, tool misuse, connector abuse, or misrouted action can become a real change instead of a blocked attempt. The safer pattern is task-scoped access with runtime checks, so the agent only receives permission when a specific policy condition or work item requires it.

For agent deployments, least privilege has to be operational, not rhetorical. That means removing broad tokens, shared service credentials, and open-ended approvals that outlive the work they were meant to support. AI Agent Authorisation Guide is a useful reference for task-scoped and just-in-time access patterns, while Zero Trust for AI Agents frames the same problem as removing standing privilege and enforcing policy per action.

Production readiness improves when access is revocable without waiting for a human to notice something is wrong. If revocation, timeout, or policy change cannot stop the agent quickly, then access is still too durable for a production workload. That is especially important where the agent can chain several low-risk actions into one high-impact outcome.

What must be true before you promote the agent to production

Before rollout, access should be scoped, logged, and revocable at runtime. Scope tells you what the agent may do, logging tells you what it actually did, and revocation gives you a way to contain mistakes or abuse. Those three conditions work together, and production should wait until all three are demonstrated in the environment the agent will really use.

Logging is not just for after-the-fact forensics. You need enough detail to attribute each meaningful action to the agent, the request, and the policy decision that allowed it. AI Agent Observability, Audit and Incident Response Guide is relevant here because it focuses on agent action logging, attribution, and kill-switch design. Browser and Computer-Use Agent Security Guide is also useful when the agent operates through an existing user session, since that changes what must be isolated and logged.

Runtime revocation should be tested, not assumed. If you cannot demonstrate that an access grant can be withdrawn cleanly while leaving the rest of the service intact, then the agent still has operationally fragile access. That is a rollout blocker because the first real incident will otherwise become a manual cleanup exercise instead of a controlled containment step.

Risk and Threat Considerations

Standing access is attractive to attackers because it turns a single compromise or prompt-induced mistake into repeated, authorized actions. The biggest exposure is not the initial request, it is the durable permission that lets the agent continue operating after the original task, context, or trust assumption has changed.

Failure mechanism: Overbroad or persistent access lets a compromised prompt, poisoned input, or misused tool produce real production actions without a fresh policy decision, which expands blast radius and weakens containment.

Impact: Unnecessary standing privilege can lead to unauthorized changes, data exposure, lateral reach into connected systems, and slower incident response because revocation and attribution are harder.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Agent access scope and standing privilege are the core concern here.
	NHI-07 — Long-Lived Secrets	Production rollout hinges on avoiding durable credentials that outlast the task.
	NHI-01 — Improper Offboarding	Runtime revocation and clean removal of access are required before production.
Recommendation — Remove broad agent permissions and enforce least privilege for each task. Replace persistent secrets with short-lived access and rotation. Ensure agent access can be revoked quickly when the workflow ends or changes.
NIST Zero Trust (SP 800-207)	Zero Trust Architecture	The question is about verifying each action and removing standing privilege.
Recommendation — Apply continuous verification and least privilege to every agent action.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Scoping agent access to only needed actions is the central control choice.
	AU-2 — Event Logging	Production readiness depends on logging agent actions for attribution and review.
	IA-5 — Authenticator Management	Revocable runtime access depends on managing and retiring the secrets or tokens behind the agent.
Recommendation — Limit agent permissions to the minimum required for the current task. Log agent activity with enough detail to attribute and investigate actions. Use managed, revocable authenticators instead of durable shared credentials.
NIST CSF 2.0	PR.AA-05 — Least Privilege	The answer directly requires removing standing access and scoping authority.
	DE.CM-01 — Network Monitoring	Logging and runtime visibility are needed to see agent actions and revoke access quickly.
Recommendation — Enforce least privilege for agent access paths and tool permissions. Monitor agent-connected systems so abnormal access can be detected and stopped.

Practitioner Guidance

What to prioritise: Treat reachable-system inventory and access scoping as a release gate, not a documentation exercise. If the agent can touch production data or control planes, verify each path, each permission, and each revocation point before pilot traffic is allowed.

What to verify: Confirm that access is conditional, time-bounded, and observable in the real runtime path. The practical test is whether a policy change or token withdrawal immediately stops the agent from repeating the same action.

Common mistake: Teams often approve the agent’s intended task and forget the tools behind it. That is where standing privilege survives, especially through inherited sessions, shared connectors, or generic service tokens.

Practitioner takeaway: A production agent is ready only when its authority is narrower than its capability, and when every meaningful action can be explained, limited, and revoked without delay.