Securing AI agents: four questions before an agent gets access

Who it's for

Anyone using, or planning to use, AI agents that are allowed to write to real systems — email, CRM, accounting, orders.

What you'll be able to do

Know the four questions an agent has to answer before it gets access, and how to answer them without a major security project.

As of

September 2026

What happened on 22 September

Twelve vendors have agreed on the same answer. Okta, together with AWS, CrowdStrike, Databricks, Docker, Google Cloud, Lovable, Proofpoint, Salesforce, ServiceNow, Wiz and Zscaler, has founded the "Blueprint Alliance".¹

The aim is an open blueprint, a reference architecture, that lets businesses run their AI agents as one governed system — across model providers, data platforms and applications. A first version of the blueprint appeared in March 2026; the alliance has expanded it and opened it up to multiple vendors.¹

The announcement describes the reason itself: there is a gap in which unknown agents multiply, credentials cross trust boundaries and agents do more than they are meant to.¹

Announced

22 Sep 2026¹

Blueprint Alliance

Founding members

12¹

identity, cloud, security, data

Principles

6²

for securing agents

Questions

4¹

the core of the blueprint

It's worth putting this in context. This is a coalition of vendors that sell security, identity and cloud products themselves. Okta, for one, describes itself in the same announcement as a company that secures AI, machine and human identity.¹ The blueprint is still useful, because it isn't tied to a product. The four questions apply even if you buy none of them.

The six principles

The members have agreed on six principles. The alliance's website lists them like this:²

• "Every agent is a distinct security identity" — each agent is its own identity, provisioned, authenticated and deprovisioned like an employee.
• "Access is scoped to the task, not standing" — permissions apply to one task and are revoked afterwards, instead of existing permanently.
• "Delegation is traceable end-to-end" — every action traces back to the person or process that authorised it.
• "Runtime behavior is monitored, not just provisioned" — what gets watched is what the agent does, not just what it is allowed to do.
• "Containment is instant and reversible" — every agent needs an immediate off switch and a clear way back.
• "Governance adapts at the velocity of AI" — the rules grow with the agents' capabilities.

The idea is old; only the use case is new. Anyone who has set up logins for a new employee and removed them when that person left knows the principle. The alliance explicitly applies it to agents and calls this an extension of zero trust, the principle of not trusting anyone on the network without checking.²

The four questions

The blueprint arranges everything under four questions.¹ For each, I describe below how I would answer it in a business with only a few agents. That is my recommendation, not part of the blueprint.

1. Where are my agents?

"Enterprises cannot govern or protect agents they do not know exist," the announcement says.¹ You can't secure what you don't know about.

For a mid-sized business, that's a list, not a product. For each agent: what it does, which systems it accesses, who is responsible for it, since when it has been running. It's the same exercise as the AI inventory, with one extra column for access. Don't forget agents built into software you've bought, and ones someone on the team has set up themselves.

2. What can they do?

The blueprint calls for access scoped to the task rather than standing privilege, and for delegation to stay traceable when agents spawn sub-agents or act on behalf of people.¹

The most common shortcut is the most dangerous one: the agent runs on a person's login. Then every action in the log looks as if your colleague had done it herself, and nobody can take permissions away from the agent without taking them from her too. A separate login for each agent, with exactly the permissions its task needs, costs set-up time once.

The post on AI agents in practice has a rule for this: the agent may create drafts, not publish. It's the same idea on a small scale — the agent prepares, a person approves.

3. What are they doing?

The blueprint wants policies enforced during execution, through gateways in the execution path, and behaviour observed continuously to catch data leakage, injected instructions and anomalies.¹

Injected instructions are what sets agents apart from ordinary software: an agent that reads emails also reads the instructions a stranger writes into an email. It may well follow them.

To begin with, a complete log that someone actually reads is enough. Every tool call with time, agent, target and result. Add the blueprint's question of which systems an agent can reach at all — the announcement gives data stores and payment systems as examples.¹ Once you've answered that, you know how big the damage gets in the worst case.

4. How do I respond?

Targeted measures rather than a total shutdown: block access, limit requests, revoke keys, end the session. And afterwards a deliberate, documented readmission.¹

Try the off switch before you need it. If you want to block an agent's access and discover it runs on a shared key that three other workflows also use, you'll switch off more than you meant to when it counts. With a separate login for each agent (question 2), the off switch is one click.

What the AI Act adds

The blueprint is a recommendation from vendors. But there is already one legal duty for agents: since 2 August 2026, Article 50 of the AI Act has required that people are told when they are interacting with an AI.³

The European Commission's guidelines get specific about agents: agents that, for example, make bookings, handle correspondence, negotiate or make purchases should be designed to disclose that they are artificial — and on whose behalf they are acting.⁴ Purely machine-to-machine calls between agents whose outputs aren't meant to reach a person are not covered.⁴

That fits the blueprint's second question: if you can trace on whose behalf an agent is acting, you can also tell the other side. More on labelling in the post Labelling AI.

And on liability, what the Higher Regional Court of Hamm decided for chatbots applies: whoever deploys a system and defines its scope is held responsible for what it says.⁵ An agent that places orders is unlikely to be treated differently — though I don't know of a judgment on that. Details in the post When your chatbot gets it wrong, you said it.

Where I stand

The blueprint says nothing a careful IT manager wouldn't already know. Its value is that it's now written down, with twelve vendors signed up to it. If you commission a service provider to build an agent, it gives you a list to measure them against.

What I wouldn't do is start with a new security product. The announcement thinks on a different scale: it cites a Gartner prediction that by 2028 an average global Fortune 500 company will have over 150,000 agents in use.¹ A business with five agents needs a list and separate logins first.