You can't govern AI agents you can't list

The first agent governance document is a list. Policy comes second, and most policies get written first. AI agents went out of scope at 65% of the enterprises EMA surveyed, and 47% of the same sample could not produce a reliable inventory of the agents they were meant to be governing. Those two numbers describe the same company.

The missing list costs you the pilot, then the project behind it

A company that cannot list its agents cannot scope them. It cannot audit them either, so the security team pauses the pilot and the business concludes that agents are risky. In EMA's sample, 30% of agentic pilots had been paused with no restart date or discontinued, and 48.5% of respondents cited security risk as a major concern. The automation the pilot was meant to deliver stays undelivered, and the hours it was meant to free stay spent.

Detection speed is the other cost. 54.5% of respondents needed hours and manual intervention to detect and contain an out-of-scope action. An agent that sends one email a minute and goes wrong at 9 AM has sent 180 by the time someone on an hours-scale process gets to it.

The inventory: one week, one question, four fields per agent

Ask each department head one question: what runs here without a person clicking? Write the answers down, one row per agent, and record four fields against each.

• AGENT. The row itself: its name, the vendor or internal team that built it, and what it does in one line.
• OWNER. One person by name. A team, a vendor or "IT" fails the field.
• CREDENTIAL. The login it runs under, and if that login is shared with a person or another system. Shared fails the field.
• READ/WRITE. The systems it can reach, with read and write on separate lines. "All" fails the field.
• KILL SWITCH. The person who can revoke the credential today without asking anyone. If revocation needs a ticket, the field is empty.

A failed field is a governance finding on its own, before any policy exists. The exercise can surface agents that appear on no central record, including the one a vendor switched on at renewal and the one in marketing that posts on a schedule. Those are the ones that end up in the 65%.

Three moves once the list exists

• Give each agent its own login, separate from any person's credentials and from any shared service account. A separate credential makes the agent's actions separable in the log, and separable actions can be alerted on and cut off with one revocation.
• Write the scope as permissions on that login. Keep the paragraph in the policy document as a description of what the permissions already enforce.
• Name the person who reads the agent's log each week and can pull the credential the same day.

None of the three needs a security vendor. All three need the list.

What EMA found

Source facts, reported by Alessandro Mascellino in Infosecurity Magazine. Agents Without Guardrails, by Enterprise Management Associates for Cequence Security, surveyed 202 enterprise technology and security leaders. 65% had experienced an agent acting outside its intended scope. 47% lacked a reliable agent inventory. 46% could not produce a complete 30-day audit trail. 94% were at least somewhat confident their agents held no more access than needed, and 32.7% had provisioned agents with least privilege. 32.2% could detect and contain an out-of-scope action within minutes; 54.5% needed hours and manual intervention. Seven organizations, 3.5% of the sample, first learned of an issue from a customer or partner.

Christopher Steffen, VP of research at EMA: "The gap is between what's written down and what's enforced."

My reading of the 94 and the 33, not EMA's: the 94% are confident in a document. The 33% are confident in a login. A policy that says the agent may only read the ticketing system enforces nothing by itself. A credential that can only read the ticketing system enforces the policy without anyone reading it. You cannot put the rule on a credential for an agent that is not on the list.

Agents that go on the list before they run get scoped before they run

That is the whole sequence. Inventory, then credential, then permissions, then a named person with the kill switch. The policy document describes what those four already enforce.

The four-field inventory is a one-page template Yellow Brick uses at the start of agent work. If you want the page, message me the word "inventory" and I will send it.