On October 16, Anthropic published how employment is changing inside the company. One figure stands out. In March 2026, the combined hours worked by its autonomous and interactive agents passed the hours worked by its employees for the first time. By August, agents directed by individual employees worked six times as many hours as their human handlers.
Read the caveats before quoting the number. It describes one company at the frontier of adoption. Agent time is measured as runtime, including inference and tool use. Human time is headcount multiplied by an assumed 40-hour week. The authors note that adoption was not random and that the company was growing fast, so the productivity estimates have limits.
The security point survives every caveat. When agents work more hours than people, most of the activity under your credentials is no longer human. Your security model was built for occasional AI interactions: a person asks, a model answers. It now has to cover persistent machine identities doing work continuously, often while no one is watching.
Why your AI register is not an agent inventory
Most organizations already have a list of AI. It usually names vendors and use cases: "Copilot for engineering," "chatbot on the support site," "contract summarization pilot." That list answers a procurement question. It does not answer a security one.
An incident responder needs different facts. Which identity did this agent act as? What could it reach? Who owns it? How do we stop it? The incident response practices NIST, NSA and CISA published in October assume you already know. Practice 3.1 asks you to define each agent's intended scope so you can detect deviations. Practice 1.7 asks for a way to terminate agent activity quickly. India's CERT-In, after agents under evaluation reached live corporate systems, told organizations to give each agent run its own short-lived, least-privilege identity.
Every one of those controls presupposes an inventory with the right columns.
Microsoft reached the same conclusion on October 19. In Agents are your newest insiders, it argues that every agent needs "a first-class identity distinct from the person using or sponsoring it," should start with no permissions, and should run inside a controlled environment, with the controls sitting outside the model. Its summary: "We should not ask a model to be its own security authority." An inventory is how you check that this holds for each agent, one record at a time.
The ten fields
One record per agent. An agent here means anything that takes actions with tools under an identity: a coding agent in your pipeline, a support agent that issues refunds, an automation that reads email and files tickets. For each field, the question to ask and the answer that should worry you.
- Agent. What is it, and what is its job in one sentence? Red flag: the description is a product name, not a task.
- Owner. Which named person is accountable for its behavior and gets paged when it misbehaves? Red flag: a team alias, or the person who built it and has since moved on.
- Identity. Which account, key, or token does it act as? Red flag: a human's personal token, or a service account shared with other systems. Its actions cannot then be told apart from anyone else's.
- Tools. Which tools, APIs, and MCP servers can it call? Red flag: "whatever is configured," or a general-purpose shell.
- Data. What data can it read, and what can it write, change, or delete? Red flag: access inherited from a broad role rather than granted for the task.
- Privileges. Which consequential actions can it take without a separate approval: payments, external messages, production changes, permission grants? Red flag: any of these with no gate the agent does not control.
- Network. Which destinations can it reach? Red flag: unrestricted internet egress. Anthropic's agents worked around a tool restriction with a public URL shortener; a network allowlist that did not include the shortener would have refused the request.
- Runtime. Where does it run, how often, and for how long? Red flag: on a developer laptop, or continuously with no one assigned to watch.
- Telemetry. Where are its tool calls, destinations, and control decisions logged, and who controls those logs? Red flag: only in the vendor's console, under the vendor's retention policy.
- Kill mechanism. How do you stop it and revoke its credentials, how long does it take, and when was that last tested? Red flag: "we would disable the API key," with no idea which other systems share it.
If you cannot fill in a field, you have not failed the exercise. You have found the first finding.
A worked example
Here is the record for a common case: an AI coding agent that runs in the CI pipeline, fixes failing tests, and opens pull requests. The values are illustrative, typical of what a first pass finds.
- Agent. Fixes failing tests on feature branches and opens a pull request with the change.
- Owner. Platform engineering lead, named.
- Identity. A GitHub App installation scoped to three repositories. Finding: the pipeline also exposes a deploy token as an environment variable the agent can read.
- Tools. Repository read and write, test runner, package registry.
- Data. Source code and test fixtures. Finding: one fixture file holds a production database snapshot.
- Privileges. Can push to feature branches. Cannot merge; branch protection requires human review.
- Network. Finding: unrestricted egress from the CI runner.
- Runtime. Ephemeral CI runner, triggered on each failing build, about 40 runs a day.
- Telemetry. CI logs kept 30 days in the CI platform. Finding: tool calls and fetched URLs are not logged.
- Kill mechanism. Disable the GitHub App. Finding: never tested, and revoking it does not revoke the deploy token.
That took less than an hour, and it produced five findings, each with an obvious fix: remove the deploy token from the job, scrub the fixture, put an egress allowlist on the runner, log tool calls to the central log platform, and add a tested revocation step to the runbook. None of them required a governance framework.
Where agents hide
The first record is easy because you chose the agent. The hard part is the ones nobody told you about. Look in these places:
- Your identity provider. Non-human accounts, OAuth grants to AI applications, and tokens issued in the last six months.
- Model provider consoles. API keys issued under your company's accounts, and who created them.
- Egress logs. Outbound traffic to model API endpoints, from which hosts.
- CI/CD and automation platforms. Jobs that call a model, and the secrets those jobs can read.
- SaaS admin panels. Agent features switched on inside tools you already pay for, with the permissions of whoever enabled them.
- Developer machines. Coding agents and local MCP servers running with the developer's own credentials. Microsoft's discovery tooling now recognizes 60 types of local agents, including Claude Code, OpenAI Codex and GitHub Copilot. That is the scale of what can arrive without a deployment process.
- Expense reports. AI subscriptions bought on a corporate card.
Each source finds agents the others miss. Run all of them once, then make the inventory a gate: no agent gets a production credential without a complete record.
What the inventory unlocks
The inventory is not the goal. It is the prerequisite for everything else.
- The reconstruction test. For each agent, could you rebuild its last 24 hours from your own logs? The telemetry field tells you before an incident does.
- Near-miss counting. Blocked attempts only mean something per agent, against its declared scope.
- Board reporting. Directors do not need the records. They need counts: how many agents, how many with a named owner, how many with a tested kill mechanism. Our post on board questions before an AI coding tool rollout shows the format.
- Control mapping. On October 20, NIST renamed its project to adapt SP 800-53 to these systems COSIS: control overlays, not a separate framework. The inventory already speaks that language. Agent and owner are a component inventory (CM-8). Identity maps to IA, tools, data and privileges to AC and least privilege (AC-6), network to boundary protection (SC-7), runtime to configuration management (CM), telemetry to audit (AU), and the kill mechanism to incident response (IR). Your auditors already know these families.
- Privacy assessments. Under Quebec's Law 25, the data field feeds the privacy impact assessment the law requires for information system projects involving personal information.
How we help
Our GenAI Security Readiness Assessment starts with this inventory. We discover the agents, build the records with your owners, test the kill mechanisms, and turn every gap into a finding with an owner, a severity, and a remediation. You keep the inventory and the process to maintain it.
Three questions to test yourself
- How many agents run in your environment today? If the answer is a guess, the inventory is your first task.
- For your most privileged agent, could you fill all ten fields from memory, or from a document that is less than a quarter old?
- Which of your agents could you stop, with every credential revoked, in under fifteen minutes?
Pick one agent this week and fill in its record. The first one takes an hour. It is also the first evidence that your agent governance exists outside a policy document.