Your Next Privileged User May Not Be Human. Start With an Agent Register.

In September 2026, two separate surveys landed on the same uncomfortable finding. Enterprise Management Associates, in research for Cequence Security, polled 202 enterprise technology and security leaders and reported that 47% lacked a reliable agent inventory, 65% had seen AI agents act beyond their intended scope, and 46% could not produce a complete 30-day audit trail. In a separate study, Guild.ai, with a Morning Consult survey of 362 IT decision-makers, found that 96.4% believed they had a complete and accurate agent inventory, yet only 35.9% required agents to be registered before deployment.

Read together, the numbers describe a confidence gap rather than a technology gap. Leaders believe they know what is running. The controls that would prove it, such as mandatory registration, centralized monitoring and complete logging, are missing in most organizations. For a CISO, a Chief Audit Executive or a bank’s head of technology risk, that is the definition of an unmanaged population of privileged actors.

We have already covered the identity side of this shift in why the fastest-growing identity in your enterprise isn’t human. This piece is the operational follow-up: the concrete artefact, an AI agent register, that turns “Know Your Agent” from a slogan into something an auditor can test. The model will feel familiar to anyone who runs third-party risk. A vendor register tells you who you depend on, what they can touch and how critical they are. An agent register does the same for the autonomous actors inside your own perimeter.

The Counting Problem: Why Agents Escape the Inventory

Traditional identity governance assumes people join, move and leave through HR processes, and applications arrive through procurement. Agents break both assumptions. A developer can connect a model to a finance application with an API key, or a business user can authorize an OAuth grant to an agent platform, in minutes and with no ticket. The agent then acts continuously, often with the permissions of whoever created it, and often outlives the experiment that justified it.

The EMA research shows how this plays out after the pilot. About 30% of pilots had been indefinitely paused or discontinued, frequently with credentials still active. Only 34.2% evaluated an agent’s authorization at execution time, and just 32.7% provisioned agents with least privilege, even though 94% of respondents expressed confidence in their approach. An abandoned agent with live credentials is the non-human equivalent of a terminated employee whose account was never disabled, a finding auditors already know how to write up.

There is a second reason agents escape counting: the word itself is slippery. Some teams mean a chatbot, some mean an automation script with a model call, and others mean a multi-step system that plans and executes. For governance, the useful definition is functional. An agent is any AI-enabled component that holds credentials or tokens and can take action on a system without a human performing each step. That definition includes the agents embedded in SaaS products your vendors operate, which is why the register and your third-party program have to meet. Our earlier piece on shadow AI as the new shadow vendor problem explains that overlap.

The Agent Register: Ten Fields That Turn KYA Into a Control

The register’s logic is a chain: Agent → Owner → Purpose → Systems → Permissions → Data → Risk Tier → Controls → Activity → Exceptions. Each link answers a question an auditor, regulator or incident responder will eventually ask. Grouped into five pairs, the ten fields look like this.

Two design points separate a useful register from a documentation exercise. First, the register is populated by discovery, not by forms. Identity providers, secrets managers, API gateways, cloud IAM, SaaS admin logs and agent platforms all emit evidence that an agent exists. Self-registration is welcome, but every record should be reconcilable to those signals, and every signal without a record is an exception. Second, the register is owned jointly. IAM or security usually runs it, risk sets the tiering, and internal audit tests it independently, which mirrors how mature organizations already govern privileged access.

What Internal Audit and the CISO Should Test

With a register in place, assurance becomes concrete. The IIA’s Global Internal Audit Standards expect internal audit to provide assurance over governance, risk management and control processes, including technology risk. Applied to agents, five tests carry most of the value.

• Completeness. Does the register reconcile to OAuth grants, API keys, service accounts and agent-platform inventories? Unregistered agents found by discovery are the headline metric.
• Accountability. Does every agent have a named, active owner who can explain its purpose? Orphaned agents are a design failure, not an administrative gap.
• Least privilege. Do granted permissions match stated purpose, and are they re-evaluated at execution time rather than only at provisioning? Compare entitlements with actual usage.
• Traceability. Can an action be attributed to a specific agent, with enough context to reconstruct what it did and why? Shared credentials, which a small share of respondents still allow, break attribution entirely. Our analysis of the AI agent audit assurance gap and why AI agents need audit trails go deeper on this.
• Containment. Can a misbehaving agent be paused or revoked quickly, and has that ever been tested? With only 31% reporting automated kill switches, this is where incident response plans are most often theoretical.

These tests also give structure to the COSO view that governance must be expressed as operating controls. If you want the framework mapping, see our piece on why an AI policy isn’t an internal control until someone tests it, and for the independence question, why AI may need its own independent assurance layer.

Lifecycle: From Provisioning to Decommissioning

Registers fail when they capture birth but not death. The same discipline applied to joiners, movers and leavers needs a non-human equivalent. At creation, the agent is registered, tiered and given the minimum access its purpose requires. While operating, its permissions are recertified on a cadence set by risk tier and whenever its scope changes, which is the same logic described in why permission reviews are becoming continuous controls. When the pilot ends, the owner leaves or the vendor relationship changes, credentials are revoked and the record is closed with evidence.

Tiering also decides how much human oversight each agent needs. A read-only summarization agent may need periodic review. An agent that can post journal entries, change vendor bank details or grant access should require approval checkpoints and transaction limits, with every exception logged. This is the practical meaning of human-in-the-loop governance: oversight sized to consequence, not applied uniformly. ISACA’s COBIT and the COSO framework both give the vocabulary for linking these controls to enterprise objectives.

For regulated sectors, the register has a further use. Banks and insurers asked to show operational resilience, outsourcing oversight and access control to supervisors can present one artefact that shows which autonomous actors run material processes, who owns them and what constrains them. Global enterprises and GCCs operating across jurisdictions benefit from the same single view, because the register is independent of any one regulation and can be mapped to each. It also feeds directly into the broader AI inventory that governance programs need first.

Building the Register: A Six-Step Playbook

Crest.Digital delivers this as a configurable “Risk Automation Pod” rather than a bespoke build. The reusable stack of integration connectors, agent orchestration, evidence capture and exception workflow is configured around your identity and control environment, so a first reconciled register is measured in weeks.

For boards and audit committees the takeaway is three questions. How many agents do we have, and how do we know the number is complete? For every agent that can change a financial, customer or access record, who owns it and what limits what it can do? And when an agent acts outside scope, how quickly do we find out, and where is the record? If the honest answers are estimates rather than system-generated figures, the organization has agent adoption but not yet agent governance. Our view on the agentic AI governance gap in audit testing shows how to move from estimate to evidence.

Frequently Asked Questions