What should organisations do first before putting agents into production?

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.

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.

Related resources from NHI Mgmt Group

• How should security teams limit the risk from AI agents that have access to production systems?
• How can organisations prevent AI agents from becoming overprivileged?
• How can organisations govern AI agents that use service accounts and tokens?
• How should organisations test generative AI chatbots before putting them in production?