More identities need clearer accountability.

Ownership comes before scale.

Service accounts, workloads, integrations and AI agents act across an organisation without following the same journey as an employee. Their identities can outlive the project or person that created them. Permissions can accumulate while the business reason for that authority becomes difficult to find.

The question I want a business to answer is simple: who is accountable for what this identity can do? A technical creator, a human sponsor and an operational owner may be different people. Recording a name is not enough unless that person understands the purpose, authority and review responsibilities.

An agent adds a decision-making boundary.

A workload identity may be used for a defined integration or service operation. An AI agent may select tools and actions within a workflow, using its own authority or delegated authority. The terms are not interchangeable, and an organisation should define which behaviours and access paths it is trying to govern.

Authentication answers which identity is calling. Authorisation determines which resources and actions are permitted. Delegation needs to retain the relationship between the requesting person, the agent, its tools and downstream services. Model output alone should not be treated as permission to perform a sensitive action.

Human sign-in controls do not, by themselves, explain or constrain all of those machine-to-machine decisions. Policy enforcement and revocation need to exist at the relevant execution and resource boundaries.

Connect inventory to the control decision.

Discovery should produce a usable control record, not just a larger catalogue. Start with a meaningful use case, map the identity and access path, and decide what evidence is needed to keep it accountable.

• Purpose: the business process and permitted actions the identity supports.
• Ownership: the sponsor, operational owner and escalation route.
• Authority: the tools, resources, scopes and delegated permissions available.
• Credentials: how authentication material is issued, protected and renewed.
• Lifecycle: approval, review, expiry and removal when the use case changes.
• Telemetry: the grant, policy decision and action evidence needed to investigate behaviour.

Read the governance gap in context.

SailPoint's 2026–2027 Horizons report describes a survey of 340 identity, IT, cybersecurity and risk leaders at organisations with at least 1,000 employees. In that survey, 79% reported AI agents in production and 2% reported purpose-built identity security tools to govern and secure them.

Those are two responses from that sample. They do not mean that every organisation without a purpose-built tool has no governance, nor do they establish the proportion of agents that are insecure. Existing controls may contribute; the task is to establish where they apply and where gaps remain.

The important decision is what your organisation can explain today: which agents exist, what authority they exercise, what constrains it and what happens when that authority needs to stop.

Begin with one governed use case.

Choose a bounded workflow and map the people, agents, workloads and tools involved. Establish who approves its authority and test whether permissions can be withdrawn at each relevant boundary. Removing a single credential may not revoke delegated permissions, cached sessions or access already granted downstream.

Build acceptance criteria around the intended outcome. Can the team identify the owner? Can it distinguish expected from unexpected actions? Can it investigate a failed policy decision? Can it suspend the use case safely? Expand the approach once those decisions and operating responsibilities are clear.

Good governance makes adoption easier to defend. It gives the business a way to use new capabilities while keeping authority visible, deliberate and accountable.

Practical questions.