Securing AI agents starts with identity

Why AI agents are an identity question

An AI agent is software that plans and carries out tasks on its own. It reads data, calls APIs, and sometimes starts other agents. All of this requires access, and with access come the familiar identity questions: what the agent is, who owns it, and what it should be allowed to do.

Unlike a traditional service account, an agent chooses its own steps and may act on behalf of a person. Without a clear identity model, it becomes hard to answer a basic audit question: who did this, and on whose authority?

This is already happening in many organizations. Low-code agent builders and foundry services let employees build their own agents without writing code and connect them to document repositories, backend systems, and SaaS applications. The number of agents grows fast, often without oversight of what each one should do or what access it needs. The result is over-permissioned agents that stay active long after their project has ended.

A shared blueprint for securing AI agents

In September 2026, our partners Okta and CrowdStrike were among the founding members of the Blueprint Alliance, a group of twelve technology companies that also includes AWS, Google Cloud, Salesforce, and ServiceNow. Building on a blueprint Okta introduced in March 2026, the alliance is developing an open reference architecture for securing AI agents.

It is organized around four questions:

1. Where are my agent?
2. What can they do?
3. What are they doing?
4. How do I respond?

The alliance plans to update the architecture as agents become more capable, and few organizations will need all of it at once. The four questions are a good place to begin. They give security, IT, and business stakeholders a shared view of where they stand, and identity plays a part in nearly every answer.

Four questions and where to start with each

Each question builds on capabilities most organizations already have. Below is what each one covers, where the gaps usually are, and a first step that doesn’t require a large new project.

1. Where are your agents?

Start with an inventory and a named owner for every AI agent. Some agents are easily identified because your own team built them. Others arrive quietly through SaaS features, browser extensions, or employees connecting AI tools to their work accounts.

What you probably already have: a directory, an identity provider, and logs of OAuth consent grants showing which apps employees have connected.

What is usually missing: a category for agents in the directory and a named owner for each one. Without an owner, nobody reviews the access or notices when it’s no longer needed.

A practical first step: Review OAuth grants and API integrations in your main platforms and flag anything that behaves like an agent. Going forward, require an identity, a stated purpose, and an accountable owner before any agent goes live.

2. What can they do?

An AI agent’s access should match the task it’s doing. Broad access is the fastest way to make an agent work, so it’s common. A ticket-summarizing agent ends up reading the whole CRM, and an assistant inherits everything its user can reach.

What you probably already have: role-based access, access policies, and possibly Privileged Access Management (PAM).

What is usually missing: access limited in time and scope to the current task, and delegation you can track back to the person who started it.

A practical first step: Map exactly what one sensitive agent use case needs and compare it with what it has. Closing the gap gives you a pattern for the next agent.

3. What are they doing?

AI agent activity needs to be visible and traceable. Knowing what an agent may do is only half the picture. You also need to see which tool it calls, which data it touches, and whether its behavior shifts in ways that suggest misuse or prompt injection.

What you probably already have: sign-in logs, security monitoring, and possibly identity threat detection.

What is usually missing: logs tied to a specific agent and, where relevant, to the person it acts for. Agents sharing one service account can’t be told apart.

A practical first step: Give each agent its own identity so its activity shows up in your existing monitoring. Almost every later control depends on this.

4. How do you respond?

You need to be able to stop an AI agent quickly, and to know that it works. The blueprint calls this a kill switch: revoking an agent’s tokens and sessions at short notice, then restoring access safely once the issue is resolved.

What you probably already have: processes for disabling accounts and revoking sessions, built for joiner, mover, and leaver scenarios.

What is usually missing: the same capabilities for agents. Many organizations can’t say which tokens an agent holds or where they are stored.

A practical first step: Run a tabletop exercise. Pick one agent and walk through stopping it within fifteen minutes. Who decides, what gets revoked, and what breaks? The gaps show up quickly.

When AI agents act on behalf of customers and partners

Agents are also starting to act for customers and partners, placing orders, managing loyalty accounts, or checking stock through your portal.

This raises new questions: How does someone authorize an agent, and how narrowly? Where can they see and remove it? And how do you tell a legitimate agent apart from a bot testing stolen credentials?

The principles are the same as on the workforce side: a clear identity, scoped access, traceable delegation, and easy revocation. What changes is that your customer is in control, so the experience must be simple enough for them to manage.

Where to start

Getting started typically means extending the identity foundation you already have to cover a new type of identity. Alongside the first step above, two things are easy to overlook:

• Add agents as a separate category in your Identity Governance, with clear definition of what counts as an agent
• Include agents in access reviews and leaver processes, so they are removed when no longer needed

This work also supports EU regulations such as GDPR, which requires control over who and what can access personal data, and the AI Act, which emphasizes human oversight and traceability of AI systems. 

The architecture and tools will continue to evolve. Treating agents as identities from the outset creates a foundation for adding new controls as they mature, rather than addressing gaps in ownership and access later. 

How can Cloudworks help?

Our consultants work hands-on with Identity and Access Management, Customer Identity, AI security, and Zero Trust every day, with organizations across Norway, Denmark, Sweden, and Finland. We help you assess where you stand on the four questions, extend your existing setup to cover agents, and build the governance that keeps their access documented and under control.