Skip to newsletter content
Will Lassalle
The Governance Gap

Issue #14

The Fallacy of the AI Identity Perimeter

Your security team is focused on employee password changes while autonomous machine identities are holding the unmonitored keys to your master cloud databases.

Editor's note — September 12, 2026: Withdrew the unsourced 70% incident claim and illustrative 90% spending figure; distinguished workload identity from AI-agent incidents.

The take

Human and non-human identities both need protection. Service accounts, API credentials and agent identities can carry significant privileges, but a compromise of a machine identity is not automatically an AI-agent incident.

Questions worth asking

  • Who owns each privileged workload identity?
  • Which systems and actions can it reach?
  • Can its credentials be rotated or revoked without losing recovery access?
  • Are actions logged with enough context to investigate misuse?

My recommendation is to assess workload identities alongside employee access, not to replace one program with the other. The appropriate investment depends on actual permissions, exposure and business criticality.

What the board should ask management to show

I would ask for one privileged workflow, not another slide counting service accounts.

Show who owns the identity, what information it can reach and which actions it can take. Then show the boundary between a recommendation and an action. If the system can change something consequential, I want to know which limits are enforced independently of the model and who can intervene.

A workload identity used by an AI agent is still an identity. The additional governance question is whether a changing instruction or decision process can use that identity in a way management did not intend. Protecting credentials is necessary, but it does not by itself define acceptable authority.

A decision record worth bringing to the board

Management should be able to connect four things:

Who is accountable?

A named business owner and a clear escalation route

What authority was delegated?

Allowed data, systems and actions, with explicit exclusions

Why is that boundary acceptable?

Evaluation results, permission tests and documented residual risk

How do we contain a mistake?

A tested stop/recovery procedure and an activity record

The board does not need to approve every technical permission. It needs assurance that management has a credible decision process and knows when material changes require another review.

I would distinguish three situations in the report: an approved boundary supported by evidence, an exception that a named owner has accepted, and a capability that is not yet approved. Treating the third as the first is where governance breaks down.

This is an oversight recommendation, not a claim that every workload identity is an AI agent or that one checklist satisfies every legal requirement.

For my executive and board background, see my board profile.

Source and further reading: Primary reference. Framework guidance is not a statement that a particular law applies to every organization.