Your Quarterly Access Review Covers Humans. It Misses 82 Machine Identities Per Employee.

The quarterly access review is a fixture of compliance programs in every regulated industry. Pull the list of users. Check who still needs access. Remove the stale ones. Sign off. Close the finding.

It is a reasonable process for a world where most API access belongs to human users.

That world no longer exists. For every human employee, there are now an estimated 82 machine identities — service accounts, API keys, bots, and autonomous AI agents — operating against enterprise infrastructure, according to research aggregated in Salt Security's 1H 2026 State of AI and API Security Report. Gartner projects that 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5% last year. Each of those agents arrives with credentials, scopes, and an expected lifecycle — and most of them are never included in an access review.

This is the access governance gap that is quietly driving a wave of incidents. 88% of organizations reported confirmed or suspected AI agent security incidents in the last twelve months, with healthcare reaching 92.7%. When researchers dig into the root cause, a consistent pattern emerges: not a zero-day, not a novel attack technique — a stale credential attached to a machine identity that nobody had reviewed in months.

What "82 machine identities per employee" actually looks like

The 82:1 ratio sounds abstract until you inventory the machine identities that already exist in a typical mid-size enterprise:

Service accounts for integrations. Every SaaS integration, data pipeline, and internal service call runs under some credential. These were created when the integration was built, often with broader scopes than necessary, and rarely revisited unless something breaks.

CI/CD and automation credentials. Deployment pipelines, test runners, and infrastructure automation tools each carry API access. These credentials tend to accumulate over years as teams add new pipelines without decommissioning old ones.

AI agent credentials. This is where the growth is happening now. An AI assistant for the sales team, an agentic workflow for finance reconciliation, a code review agent in the engineering environment, an MCP client for the internal knowledge base. Each pilot that becomes a production deployment, and every new agent framework deployment, adds to the count. Unlike service accounts that call fixed endpoints, AI agents call APIs dynamically — the blast radius of a compromised agent credential is much harder to bound.

MCP client credentials. Teams connecting AI tools to enterprise APIs via the Model Context Protocol are adding another category: MCP clients that authenticate against your gateway to discover and invoke tools. Each connected AI assistant — Claude, Cursor, a custom agent — is a distinct non-human caller with its own identity requirements.

The 82 number compounds as organizations move from experimentation to production deployment of AI agents. A pilot starts with one agent credential. Production adds five agents for five business units. Each agent framework deployment adds service-to-service calls between components. The count reaches the 80s before most security teams realize they are no longer primarily governing human identities.

Why the standard access review process fails for machine identities

Access reviews for humans work because there is an implicit lifecycle: hiring triggers provisioning, role changes trigger access modifications, offboarding triggers deprovisioning. HR systems, identity providers, and ticketing workflows are built around this lifecycle. Humans generally cannot silently accumulate access — someone has to approve it.

Machine identities have none of these natural checkpoints.

No offboarding event. When an AI agent pilot ends, the agent stops being used. But the credential it authenticated with does not expire automatically. It remains valid, often with the same scopes as the live deployment, sitting in a config file or environment variable that nobody has revisited. CybelAngel's API security research found that missing or abandoned authentication credentials account for 17% of all API incidents — the leading category. A significant share of those are not credentials that were stolen; they are credentials that were simply never deprovisioned.

No owner field. Service accounts and AI agent credentials are often provisioned by an engineer during development. That engineer moves to a different team. The credential has no formal owner in the identity management system. Nobody is responsible for its quarterly review because nobody is explicitly assigned to it. This is not an edge case — it is the default state for most machine credentials created outside a formal service account provisioning workflow.

No rotation cadence. Human passwords expire. Human MFA tokens are tied to physical devices. Machine credentials — API keys, service tokens, static MCP credentials — often have no expiry date at all. The 2025 audit of public MCP server configurations found 53% of MCP servers relying on static API keys. Static keys do not expire, do not scope to sessions, and produce no per-call identity signal in logs. A key provisioned in 2024 for a development environment is functionally the same as a key provisioned today — except it has had an additional year to surface in a leaked configuration file, a GitHub repository, or a compromised developer environment.

No scope review. When service accounts are provisioned for AI agents or integrations, the initial scope is often broader than necessary because the full access requirements are not yet known. The principle is to start permissive and tighten later. In practice, "tighten later" becomes "never reviewed." The agent that needed read-write access during a pilot retains it in production, long after the pilot scope was clarified and write access was no longer required.

The compliance evidence problem

For regulated industries, the access review gap creates a specific audit exposure that goes beyond the operational risk.

Banking, healthcare, government, and financial services organizations face regulators who ask a specific question during audits: "Show me that only authorized identities had access to this API, that access was reviewed on a defined cadence, and that access was revoked when no longer needed."

For human users, that question has an answer: the identity provider shows who provisioned access, the access review log shows when it was reviewed, the deprovision event shows when it was revoked.

For machine identities — AI agents, service accounts, MCP clients — most organizations cannot answer the question at all. The credentials exist in environment variables, gateway configuration files, or credential stores with no lifecycle tracking. There is no review record because no review happened. There is no deprovision record because the credential was simply abandoned, not formally revoked.

The Gartner analysis of access management maturity notes that most enterprise API management deployments treat machine-to-machine credentials as infrastructure rather than identity, which means they fall outside the governance processes that apply to human access. Regulators in 2026 are catching up to what that means in practice.

What a machine-identity-aware gateway model requires

Closing the gap requires treating machine identities — AI agents, service accounts, MCP clients — as first-class identity subjects in your API governance model, with the same lifecycle requirements as human users.

Concretely, that means four things:

Per-client identity at the gateway. Not a shared service account credential that routes all agent traffic under one identity. A distinct client record per agent, per integration, per MCP-connected tool, with its own credential, scope set, and rate limit configuration. Zerq implements this through per-client credential management where each non-human caller authenticates with a named profile that maps to specific collections, endpoints, and operation types. The gateway enforces those scopes identically whether the caller is a React application, a Python microservice, or an AI agent running through the Gateway MCP.

Expiry and rotation built into provisioning. Machine credentials should have expiry dates set at provisioning time, not added later. Scheduled credential rotation — rotating API keys and certificates on a defined cadence with notifications — means the credential lifecycle is automated rather than dependent on someone remembering to review it. External secret references (e.g., via HashiCorp Vault) mean the secret value never sits in a configuration file that could be leaked.

Owner assignment and access review inclusion. Every machine credential needs a human owner responsible for its quarterly review — the same process that applies to human access, applied to the service accounts and agent credentials that access your APIs. The Zerq audit trail provides the evidence layer: who provisioned the credential, when it was last used, which endpoints it accessed. Review becomes a query against structured records, not a manual reconstruction from scattered logs.

Scoped credentials aligned to actual agent behavior. An AI agent that summarises documents needs read access to document endpoints. It does not need write access, external HTTP egress, or access to billing APIs. Zerq's policy and scope model supports per-collection and per-method scoping so credentials are provisioned with the minimum required access from the start. When the scope needs to change, it changes in the gateway configuration — not by reissuing credentials and updating twelve environment variables.

The access review in 2026

The quarterly access review is not going away. Regulators require it. Internal risk processes demand it. But the scope of what it covers needs to expand to match the actual identity surface.

At 82 machine identities per employee, the human half of your access review is the smaller half. The machine half — the AI agents, the service accounts, the MCP clients, the integration credentials — has been growing faster than the governance processes designed to manage it.

Bessemer Venture Partners' 2026 analysis frames this as the defining security challenge of the current moment: every AI agent introduces a non-human identity that requires API access and machine-to-machine authentication, and legacy identity management was never designed to handle this at scale. The organizations that are getting this right are not inventing new governance processes — they are extending the processes that already work for human identities to cover the machine identities that have the same risk profile and the same compliance requirements.

That extension starts at the API gateway, where every request — human or machine — has an authenticated identity, an enforced scope, and a structured audit record. SecurityWeek's 2026 API security analysis puts it plainly: APIs will become the dominant application-layer breach vector in 2026, and the organizations most exposed are those still treating machine-to-machine credentials as a second-tier identity class.

The credential in your config file from the agent pilot that ended six months ago is not a hypothetical risk. It is the most common root cause in the incident reports.

Zerq gives every API client — human application, AI agent, or MCP tool — a named identity, scoped credentials, enforced rate limits, and a complete audit trail from day one. Credential rotation and expiry are built into the provisioning flow, not retrofitted. See how Zerq handles access control and client management, or request a demo to run an audit of your current machine identity coverage.