Inventory should come first because organisations cannot enforce runtime guardrails on agents they have not discovered or assigned to owners. Once the fleet is visible, runtime guardrails become the next control layer for constraining actions in production. In practice, the two controls are sequential, not interchangeable.
Why inventory has to come before runtime guardrails
Runtime guardrails are only effective when you know which agents exist, who owns them, what they can reach, and which workflows they support. Discovery and ownership create the control boundary; guardrails then constrain that known fleet in production. That sequence matters because an invisible agent can still execute risky actions, but it cannot be governed consistently until it is identified and assigned to a responsible owner.
For organisations treating agent risk as an operations problem, inventory is the control that turns an abstract “agent population” into a manageable set of assets. It reveals duplication, shadow deployments, unmanaged credentials, and orphaned access paths that make runtime policy brittle. Once those basics are visible, runtime guardrails become a practical enforcement layer rather than a guess about an unknown estate. See the Shadow AI and AI Agent Discovery Guide for the discovery signals that bring unmanaged agents under governance.
That does not make guardrails secondary in importance, only secondary in order. If inventory is incomplete, runtime controls tend to be inconsistently applied, over-permissive, or silently bypassed by untracked agents and integrations. If inventory is current, guardrails can be tuned to actual roles, tool access, and business context rather than enforced as a one-size-fits-all restriction.
What changes once the agent fleet is visible
Inventory changes the security model from “hope we know all the agents” to “we can define policy for the agents we actually have.” At that point, runtime guardrails can be mapped to specific action boundaries, approval points, and least-privilege scopes. This is especially important when agents can invoke tools, call APIs, or act across systems, because the risk is not only the presence of the agent but the breadth of the actions it can perform.
The practical value of inventory is that it exposes control dependencies. A guardrail that looks strong on paper may fail if the underlying agent is shared, duplicated across environments, or running with a stale token. Once the agent population is known, teams can separate by owner, purpose, environment, and privilege tier, then apply different runtime restrictions where the blast radius justifies it. The lifecycle view in the NHI Lifecycle Management Guide is useful here because discovery, ownership, and ongoing governance are part of the same control chain.
Runtime guardrails are strongest when they sit on top of this inventory layer and govern what each agent can do in production, not what the organisation hopes it might be doing. In practice, that means policy can be tied to the discovered agent, its owner, and its permitted scope rather than to a generic “AI” category.
How to sequence the two controls in practice
The cleanest operational sequence is discovery first, then ownership assignment, then runtime restriction. Start by identifying the agent estate and closing obvious visibility gaps. Next, assign each agent to a business or technical owner who can approve its purpose and lifecycle. Only then should you enforce runtime guardrails such as action scoping, approval gates, environment segmentation, and kill-switch capability.
- Inventory every agent that can act on behalf of users, systems, or services.
- Assign an owner and purpose before granting or tightening runtime policy.
- Apply guardrails by tier, with the highest restrictions on agents that touch sensitive systems or data.
- Review whether the agent still needs its current access after each material change in workflow or tooling.
A useful decision rule is simple: if you cannot answer “who owns this agent and what is it allowed to do?” you are not ready to rely on runtime guardrails alone. Once that answer is clear, guardrails become the next control layer that makes agent behaviour predictable in production. For a practical control model, the AI Agent Authorisation Guide shows how least privilege and per-action decisions fit after discovery and ownership are established.
Where organisations get into trouble is trying to use runtime policy as a substitute for basic asset visibility. That usually produces inconsistent enforcement, weak exceptions management, and a false sense of control.
Risk and Threat Considerations
When inventory is missing, runtime guardrails can only protect the agents you already know about. Shadow agents, duplicated deployments, and forgotten test instances may continue operating outside the intended policy boundary, which creates an exposure gap even if the visible fleet is well controlled.
Failure mechanism: Unseen agents retain their existing access, credentials, or tool connections because there is no inventory-backed owner, policy scope, or decommissioning workflow to constrain them.
Impact: Organisations can end up with unmanaged production actions, hidden blast radius, and delayed containment if an agent is misused, misconfigured, or compromised.
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 SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Agents left undiscovered cannot be retired or decommissioned safely. |
| NHI-05 — Overprivileged NHI | Inventory enables least-privilege tuning before runtime enforcement. | |
| NHI-06 — Insecure Cloud Deployment Configurations | Untracked agents often sit in misconfigured production environments. | |
| Recommendation — Remove orphaned agents and revoke their access when they no longer have an owner or purpose. Reduce each agent’s permissions to the minimum needed for its approved task. Review deployed agents for exposed execution paths and tighten environment controls. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Agent inventory is fundamentally a component discovery and ownership problem. |
| AC-6 — Least Privilege | Runtime guardrails operationalise least privilege for agent actions. | |
| AU-2 — Event Logging | Runtime guardrails need logging to confirm agent actions and enforcement. | |
| Recommendation — Maintain an authoritative inventory of all deployed agents and their owners. Limit each agent to the minimum access and actions required for its role. Log agent actions and policy decisions so enforcement can be validated and investigated. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems inventory | The question turns on discovering and tracking the agent fleet first. |
| PR.AA-01 — Identities and credentials issued, managed, verified, revoked, and audited | Guardrails depend on controlling the credentials that let agents act. | |
| Recommendation — Build and maintain an inventory of agents before relying on runtime restrictions. Manage agent credentials so runtime policy can be enforced against known identities. | ||
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Agent discovery is an asset inventory problem before it is a policy problem. |
| CIS-5 — Account Management | Owners and access scopes must be assigned before runtime guardrails can be effective. | |
| Recommendation — Track every agent as an enterprise asset before applying production restrictions. Tie each agent account to an owner, purpose, and reviewable access scope. | ||
Practitioner Guidance
What to prioritise: Close visibility gaps before you tune policy thresholds. If the estate is not discoverable, guardrails will be uneven by design because they will only cover the known subset.
What to verify: Each production agent should have an owner, a purpose, and a current access scope that can be reviewed against the runtime policy actually enforced. If any of those three are missing, treat the agent as a governance gap, not just a tooling gap.
What good looks like: The organisation can enumerate its agents, map them to owners, and then show that runtime restrictions are applied according to sensitivity and business function rather than by ad hoc exceptions.
Practitioner takeaway: Inventory is the prerequisite control because it defines the target population; runtime guardrails are only reliable after that population is visible, owned, and lifecycle-managed.
Related resources from NHI Mgmt Group
- Should organisations prioritise external exposure or internal credential governance first?
- Should organisations prioritise runtime controls or agent productivity first?
- Should organisations prioritise runtime guardrails or model review first?
- Should organisations prioritise agent inventory or access policy first?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org