AI Agent Inventory and Non-Human Identity: How to Discover Agents and Enforce Runtime Policy

Most enterprises trying to govern agentic AI start by writing a policy. The policy is not the problem. The problem is that nobody can name the agents already running.

An agent inventory sounds like housekeeping. It is not. It is the precondition for every other control you might want, because authority limits, human oversight, and audit trails are all statements about specific agents, and a statement about an agent you have not discovered governs nothing. This is the operational layer beneath the agentic AI governance framework: discovery, identity, and runtime enforcement.

Why agents disappear inside an enterprise

Agents do not arrive through a procurement process that produces a register. They accumulate.

A data team wires a scheduled LLM job into a pipeline. A support group turns on an assistant that can issue refunds below a threshold. A developer connects a coding agent to the repository with a personal access token. A finance analyst builds an automation that reads invoices and posts entries. A vendor's product ships an agent inside it, and the agent inherits whatever credentials the integration was given.

None of that is misconduct. Each step is a reasonable person automating their own work. But the aggregate is a population of autonomous actors that no single team can enumerate, holding permissions nobody reviewed, taking actions nobody logs in one place. Security teams have a name for the credential half of this problem: non-human identity, the service accounts, API keys, tokens, and workload identities that now outnumber human accounts in most enterprises by a wide margin. Agentic AI makes those identities consequential in a new way, because a key that used to move data now makes decisions.

The failure mode is not dramatic. It is quiet. You are asked, after an incident or by a regulator, which systems took autonomous action in a process, and the honest answer takes weeks to assemble.

Step 1: Discover the agents already running

Discovery is an evidence exercise, not a survey. Asking teams to self-declare their agents produces a list of the agents people remember. Look instead where agents leave traces:

• Identity and access logs. Service accounts, API keys, and OAuth grants with recent activity but no human session. Anything holding a token that acts on a schedule is a candidate.
• Model and inference billing. Every agent costs money at an API. Inference spend by key, project, and endpoint is one of the most complete agent censuses available, and finance already collects it.
• Integration surfaces. MCP connections, webhook subscriptions, RPA orchestrators, workflow engines, CI pipelines, and the automation features inside SaaS products your teams already pay for.
• Egress and action logs. Systems of record hold the truth about who wrote what. Entries created by non-human principals in your CRM, ERP, ticketing, and payment systems reveal agents whose existence nobody registered.
• Vendor products. Ask each significant vendor which agentic features are enabled in your tenant and what those features are permitted to do on your behalf.

Do not stop at a count. For each agent found, record what it can do, not just what it is: the systems it can write to, the money it can move, the customers it can contact, and whether any of its actions are irreversible.

Step 2: Bind every agent to a non-human identity with an accountable owner

An inventory that lists agents but not owners produces a register nobody maintains. Three fields make the difference between a spreadsheet and a control:

1. Identity. Every agent has exactly one identity of its own, not a shared credential and never a human's. Shared keys destroy attribution, and attribution is the whole point.
2. Accountable human. A named person, not a team mailbox, answerable for what the agent does. This is what turns an agent from an orphan process into a delegated act.
3. Granted authority. What this agent may decide and act on, expressed as limits rather than as permissions. Access control says the agent may call an endpoint. Authority says the agent may approve a refund below a threshold, and may not approve two in sequence for the same customer.

That third distinction is where most programmes stall. Enterprises have mature machinery for permissions and almost none for authority, so they express governance in the vocabulary they have. The result is an agent with legitimate access doing something no one authorised, which is not a security failure in any conventional sense.

Step 3: Enforce policy at runtime, not in a document

The distance between a governance policy and a running system is where incidents live. A policy that says "material decisions require human review" is a sentence. Runtime enforcement is a property: the system physically cannot complete the action without the review.

The practical test has three parts, and it is worth applying to whatever you have today:

• Can the limit be exceeded by a correctly functioning agent? If yes, it is guidance, not enforcement.
• Can the human gate be filled by a machine, or configured away by the operator running the job? If yes, it is an approval step, not an authority.
• Can the decision be reconstructed afterwards from its own record, without asking the team what happened? If no, you have logs but not evidence.

This is the difference between governing the model, governing the process, and governing the decision. Model guardrails ask whether an output behaves. Workflow approvals ask whether a process reached a stage. Neither knows what the agent was permitted to conclude, which is the question that matters once the agent acts on its own conclusion. For the risk classes this creates, see agentic AI risk.

Step 4: Make the record something you can hand to someone hostile

The output of a governed run should be usable by a person who does not trust you: an auditor, a regulator, opposing counsel, a board committee. That sets a higher bar than observability. A debugging trace is written for the team that built the system. An attested record is written for someone who will read it adversarially, years later, without context.

Practically, the record needs the inputs the decision saw, the reasoning steps it took, the authority under which it acted, the human who signed where a human was required, and a means of showing the record has not been altered since. Retention matters too: the EU AI Act's logging and record-keeping expectations for high-risk systems run on a multi-year horizon, so a ninety-day log rotation quietly destroys the evidence you will be asked for.

Where this sits relative to your existing stack

Agent discovery and non-human identity work is often owned by security, runtime policy by platform engineering, and AI policy by risk or compliance. All three are correct, and the seam between them is where agents fall through.

A workable division: security owns the identity substrate, because it already owns credential lifecycle. Platform engineering owns the enforcement point, because it owns the execution path. Risk and compliance own the authority model, because they own what the organisation is willing to be accountable for. Governance of the decision itself is the layer that binds those three into one record, and it belongs to whoever will have to answer for the outcome, which in a regulated firm is a named executive rather than a function.

The regulatory pull, in case the operational argument is not enough

The EU AI Act's high-risk regime requires logging and traceability (Article 12) and effective human oversight (Article 14), with conformity due 2 December 2027 for stand-alone Annex III systems. Both obligations are statements about specific systems, so both presuppose an inventory. The high-risk deadline moved, but the classification work did not, and an organisation that has not enumerated its agents cannot start the classification at all.

In UK financial services, the PRA's model risk management principles for banks (SS1/23, in force since May 2024) already expect fallback mechanisms, escalation paths, and real-time monitoring for models in customer-facing use. FCA-only firms are not directly in scope, but supervisory expectations on model governance run along the same lines. Agentic systems inherit those expectations and add the question the model risk regime was not written for: not whether the model is sound, but whether the action it took was authorised.

Practical sequence for the first sixty days

1. Run discovery from evidence, not from a survey: identity logs, inference spend, integration surfaces, systems-of-record write activity, vendor tenant settings.
2. Publish the register with three mandatory fields per agent: identity, accountable human, granted authority. Incomplete rows are findings, not failures.
3. Tier by consequence. Sort by irreversibility and blast radius rather than by technical sophistication. The riskiest agent in most enterprises is unglamorous.
4. Enforce at runtime on the top tier first. Move one high-consequence agent's limits out of the policy document and into the execution path, with a human gate that cannot be filled by a machine.
5. Prove reconstruction. Pick one decision that agent made last week and rebuild it end to end from the record alone. The time that takes is your real audit readiness number.

Frequently asked questions

How do we build an agentic AI governance framework for discovering agents, mapping non-human identities, and enforcing runtime policy?

In four moves, in this order. First, discover agents from evidence rather than self-declaration: identity and access logs, inference billing by key, integration surfaces such as MCP connections and workflow engines, write activity by non-human principals in your systems of record, and vendor tenant settings. Second, bind each discovered agent to its own non-human identity, never a shared or human credential, and attach a named accountable human. Third, express what the agent may decide as authority limits rather than access permissions, and move those limits into the execution path so a correctly functioning agent cannot exceed them and an operator cannot configure the human gate away. Fourth, make every governed action leave a record complete enough to reconstruct the decision without asking the team, retained on a horizon that matches your regulatory obligations. Discovery without enforcement produces a register; enforcement without discovery governs a subset you happened to know about.

What is a non-human identity, and why does it matter for AI agents?

A non-human identity is any credential that acts without a person behind it at the moment of action: service accounts, API keys, tokens, workload identities. They already outnumber human accounts in most enterprises. Agentic AI changes their significance rather than their number, because an identity that used to move data now makes decisions with consequences. If several agents share one credential, you cannot attribute an action to an agent, and if you cannot attribute it you cannot govern it, investigate it, or defend it.

How do you discover AI agents already running in an enterprise?

Look for traces rather than asking for declarations. The most complete single source is inference spend by API key and project, because every agent costs money at a model provider. Then identity logs for non-human principals with recent activity, integration surfaces (MCP, webhooks, RPA, CI, SaaS automation features), and write activity by non-human accounts in the CRM, ERP, and ticketing systems. Vendors should be asked directly which agentic features are enabled in your tenant.

How do you discover all AI agents in your organization?

You do not find them by asking, because the answer you get is the agents people remember. Work from four evidence sources instead, in this order. Inference billing by API key and project is the most complete census available, since every agent costs money at a model provider and finance already collects it. Identity and access logs reveal non-human principals with recent activity and no human session. Integration surfaces hold the rest: MCP connections, webhook subscriptions, RPA orchestrators, CI pipelines, and the automation features already switched on inside SaaS products you pay for. Write activity in your systems of record shows the agents that matter most, because an agent creating entries in a CRM, ERP, or payment system is one whose actions have consequences.

Then close the loop with your vendors: ask each significant one which agentic features are enabled in your tenant and what those features may do on your behalf. Completeness is never guaranteed, so treat the register as a living document and re-run discovery quarterly. The practical test of whether you have found them all is uncomfortable and useful: pick a business process and ask which non-human principals can write to it. If nobody can answer from a register, the discovery is not finished.

What is AI agent entitlement mapping?

Entitlement mapping is the exercise of establishing what each agent can actually do, as opposed to what it was intended to do. For every agent in the register, resolve the full transitive set: the credentials it holds, the scopes on each, the systems those scopes reach, and, critically, the entitlements it inherits through service accounts or shared keys it did not obviously own. The gap between intended and effective entitlement is where incidents live, and it is usually wider than the team expects because permissions accumulate and are almost never pruned.

Two distinctions make the map useful rather than decorative. Separate read from write, and within write separate reversible from irreversible, because an agent that can issue a refund is categorically different from one that can read the ledger. Then map entitlements against authority: an entitlement your governance model never granted is an unauthorised capability sitting dormant, and the correct response is to remove it rather than to document it. Entitlement mapping is where most enterprises discover that the riskiest agent in the estate is an unglamorous automation with a long-lived key. The sharpest case is the agent that can spend: for how purchase authority gets bounded and enforced, see authority limits for AI that spends.

What is runtime policy enforcement for AI agents?

Enforcement that happens in the execution path rather than in a document or a periodic review. The test: a correctly functioning agent cannot exceed the limit, a machine cannot fill a step reserved for a human, an operator cannot disable that gate by configuration, and the action produces a record that can be reconstructed by someone who was not there. Anything that fails those tests is guidance, and guidance does not survive contact with an autonomous system acting at machine speed.

What are the best solutions for governing an agentic enterprise?

Governing an agentic enterprise takes three layers working together rather than one product. Model governance (guardrails, evaluations, observability) tells you whether an output can be trusted. Process and policy governance (GRC platforms, workflow engines) tells you what the organisation has committed to. Decision governance, the layer this article describes, binds a specific agent to a specific authority and produces the evidence. The mistake to avoid is buying one layer and assuming it covers the other two, which is how enterprises end up with a well-monitored model taking an unauthorised action.

How do you build a governed, auditable data layer for autonomous AI agents?

Treat the data an agent sees as part of the governed decision rather than as infrastructure underneath it. That means every input is explicit and observable rather than reconstructed silently at run time, memory and retrieved context are traceable to a source, and the record of a decision includes what the agent actually saw rather than what the pipeline was supposed to provide. See data governance for agentic AI for the fuller treatment.

Conclusion

Governance programmes fail at the first step more often than the last. Enterprises write the policy, name the committee, and schedule the review, then discover that the object of all this attention was never enumerated.

Discovery, identity, and runtime enforcement are not the interesting part of agentic AI governance. They are the part that makes the interesting part true. An organisation that can name every agent it runs, say who is accountable for each, and prove what each was authorised to do has already done more than most of the frameworks currently being written.

If you want this applied to the agents already running in your organisation, request a governed pilot: we scope one high-consequence agent, move its limits into the execution path, and measure how long it takes to reconstruct one of its decisions from the record alone.