Skip to content

An agent acts. With whose permissions?

August 23, 2026 · 10 min read

On 2 August the transparency obligations of the AI Act came into force, along with the AI Office's enforcement powers over general-purpose models and the full penalty regime. Article 50 is narrower than the coverage suggested. If a person is interacting with an AI system, tell them. Mark synthetic content. Disclose the deepfake. Providers of systems already on the market got until 2 December to comply with the marking rules.

Ten days later the Financial Times published research by Dream, an Israeli cyberdefence firm, describing what happened to Taiwan's government between 1 and 4 July. A framework built on two open-source agents, Hermes and OpenClaw, ran twelve attack waves with up to eight sub-agents in parallel, each assigned its own targets and techniques. It mapped 21 connected government systems, cracked 85 employee accounts, and pulled more than 2,500 personnel records before extending to the nuclear safety regulator and at least seven energy companies. Kenny Huang of the Taiwan Network Information Center called it the first disclosed fully automated attack against a government.

Read those two facts next to each other. One regime now governs what an agent must say about itself. Nothing in force governs what it is allowed to touch. I argued in July that an agent acts and a wrapper answers. The question that follows is the one that decides whether the thing survives production: with whose permissions does it act? The moment a system takes an action rather than producing text, its permission scope becomes its capability scope. That is a product decision. Most teams are letting it happen by default.

The guardrail and the lock answer different questions

The remarkable part of the Taiwan operation is not the autonomy. It is how cheap the bypass was.

Dream's researchers found that the operators cleared the models' safety guardrails by framing the whole intrusion as authorized penetration testing. No exploit against the model. No jailbreak in the exotic sense. They described the work as a routine readiness test and the guardrail accepted the description, because accepting descriptions is the only thing a guardrail can do.

A guardrail reads intent. Authorization checks rights. An agent request passes through two gates before it reaches a system of record. The first gate is a guardrail that judges whether the request looks acceptable, and can be talked out of its answer. The second gate is authorization, which checks whether the acting identity holds the right, and cannot be argued with. Most deployments only build the first. Two gates · most builds have one Agent request Gate 1 · Guardrail “Does this request look acceptable?” Reads the intent in the words. Can be talked out of its answer. Gate 2 · Authorization “Does this identity hold the right?” Checks the actor against the resource. Cannot be argued with. Taiwan, 1–4 July 2026: the operators cleared Gate 1 by declaring the intrusion an authorized readiness test. A guardrail judges what a request says about itself. Only Gate 2 checks who is asking.

Gate 1 is a conversation. Gate 2 is a lookup. Only one of them has an opinion you can change.

A guardrail is a semantic filter. It reads the request, judges whether it looks acceptable, and returns a verdict about the words. Authorization is structural. It asks whether this identity holds this right over this resource, and the answer comes from a table, not from a judgment. The first can be persuaded. The second cannot be talked to at all.

Almost every enterprise agent shipped in the last eighteen months is built with the first and not the second. The safety work went into the prompt, the refusal training, the content filters, the eval suite for harmful outputs. All of it useful, none of it a lock. And an agent, unlike a wrapper, has something behind the gate worth reaching: a booking system, a CRM, an applicant database, a payments API. A wrapper that gets talked into a bad answer produces a bad paragraph. An agent that gets talked into a bad action produces a bad row in a system of record, under someone's name.

There is an organizational reason the second gate keeps not getting built. Guardrails belong to whoever owns the model, and authorization belongs to whoever owns identity and access. In most companies those are different teams, different budgets, and different review cycles, and the agent gets shipped by a third team that reports to neither. Each group can honestly say the thing passed its checks. Nobody owns the question of what happens when a system that was designed to be persuadable is handed a credential that was designed to be trusted.

You gave it your badge because there was no other way to ship

Okta's AI Agents at Work 2026, fielded by Apprize360 across 292 executives and 492 knowledge workers in March, has one number that explains more than the rest of the report combined.

Only a third of organizations govern agents the way they govern people A single stacked bar. Thirty-four percent of organizations apply the same security controls to their agentic workforce as to their human workforce. The remaining sixty-six percent apply weaker controls to agents than to the humans whose credentials those agents use. Controls applied to the agentic workforce · Okta, 2026 34% apply the same controls they apply to employees 66% apply weaker ones to agents than to the people whose credentials they borrow same as humans weaker 292 executives and 492 knowledge workers, fielded March 2026 by Apprize360 for Okta.

The gap is not negligence. It is what happens when the fast path to production runs through a human's session token.

Only 34% of organizations apply the same security controls to their agentic workforce as to their human one. Two thirds hold the agent to a lower standard than the person whose access it is using. The same survey found 58% of executives reporting an AI-related security incident or close call in the previous twelve months, 52% of knowledge workers using AI tools without approval, 45% of those feeding HR information into them, and more than 20% sharing login credentials outright.

I do not read that as carelessness. I read it as the shape of the shortest path. Giving an agent its own cryptographic identity, scoped to one task, with a credential that expires, means building token exchange, a service registry, and an audit path before the agent does anything useful. Handing it a human's session token means it works this afternoon. Every team under delivery pressure has made that trade, including teams that know better, and the trade compounds quietly because nothing breaks.

The word for what is missing is attenuation. Delegation is fine. A person delegating their full standing authority, indefinitely, to something that acts thousands of times an hour, is not delegation. It is impersonation with a nice interface.

What makes it urgent rather than merely untidy is the rate. Salesforce's Agentic Enterprise Index, second edition, published this month, puts the average organization at 13 activated agents in April 2026, up from 5 in February 2025, and the average time to create one at 1.9 days, down 53% over the same period. Set that against how long it takes to stand up proper machine identity, which is measured in quarters and involves teams that do not report to the person shipping the agent. Two curves, opposite directions. Every week the shortcut stays cheaper than the correct path, and the pile of agents holding borrowed credentials grows by a couple more.

In a marketplace, permission scope is product scope

This is where the abstraction stops being abstract, and it is the part I spend actual working hours on.

A two-sided talent marketplace has an asymmetry built into its data model. What a recruiter can see of the candidate pool is not a security setting somebody configured. It is a product decision, made deliberately, about what a company is allowed to know about a person before that person has agreed to anything. Point an agent at that surface with the recruiter's credentials and the agent inherits the recruiter's whole field of view, then acts across it at machine speed. The privacy design that took months of argument gets flattened by a token.

Inherited scope versus attenuated scope in a two-sided marketplace Two delegation chains. In the first, a recruiter hands their credential to an agent, which acts as the recruiter across the whole candidate pool and leaves an audit log naming the recruiter. In the second, the agent holds its own short-lived identity scoped to one role, and the log records the agent acting on behalf of the recruiter. Who the system thinks is acting Inherited Recruiter full token Agent Everything the recruiter can see. No expiry. audit log → “recruiter viewed 1,400 candidate profiles” Attenuated Recruiter scoped grant Agent identity One open role. Expires before the task could run twice. audit log → “agent#4471, on behalf of recruiter, ranked 1,400 profiles” The engine, the model and the output are identical on both rows. Only the acting identity changes, and with it everything you can prove six months later.

Same engine, same model, same output. The only variable is which name ends up in the log.

In May I wrote that the Commission's draft Annex III guidance turned on a verb: the same matching engine is high-risk when it decides and outside the perimeter when it helps. The permission question is the noun version of the same problem. Same engine, same output, different acting identity, different system in the eyes of anyone who later has to reconstruct what happened.

That reconstruction is the practical stake, and it is where I have landed after eight months in Spain's regulatory sandbox with DG IA and BBVA. Everything in Shakers' Matchmaking that gets it into the OECD.AI catalog as a reference system, and everything behind the Adigital transparency certificate, rests on one capability: a candidate can challenge an outcome and we can say what produced it. If an agent acted with a recruiter's credentials, the log says the recruiter did it. The record you need in order to answer the challenge is the exact record you destroyed. No amount of model documentation recovers it, because the loss happened at the identity layer, six months before anyone asked.

Transparency is not a document you publish. It is a property of your logs, and the identity model decides whether you have it.

The deadline moved. The data model did not.

The Digital Omnibus, agreed politically on 6 May, pushed the high-risk obligations back. Standalone Annex III systems now have until 2 December 2027, and AI embedded in regulated products until 2 August 2028. Recruitment sits in Annex III. A lot of people in HR tech read that as sixteen months of relief.

It is sixteen months of something, and which something depends on a decision most teams have not consciously made. Permission architecture is not a compliance artifact you attach at the end. It lives in the data model, in how sessions are issued, in what the audit table records as the actor. Retrofitting identity into a system that has spent sixteen months logging agent actions under human names does not mean writing a policy. It means rewriting history you cannot rewrite, because the logs already say what they say.

The obligations that did land on 2 August point the same direction anyway. Article 50 says a person must know they are dealing with a machine. It would be a strange system that discloses to the candidate "an AI system assessed you" while its own audit trail insists a recruiter did it by hand. The transparency duty is live now. The internal record that makes it true is the part nobody is being forced to build yet.

What I ask before an agent ships

Four questions, in this order. They are cheap to ask and expensive to skip, and the first one disqualifies most of what crosses my desk.

Which identity does it act as? If the answer is a person's name, stop there. Everything downstream inherits that mistake, including the audit log, including the incident response, including the answer you owe a candidate next year.

What is the smallest scope that lets it finish, and when does the credential die? Not the scope that is convenient. The scope the task actually needs, and an expiry short enough that a leaked token is worth less than the effort to steal it. CISA's agentic adoption guidance, which the Cloud Security Alliance translated into enterprise controls this month, lands in the same place: cryptographically verified agent identities, short-lived credentials, least privilege enforced structurally rather than requested politely.

Which actions are irreversible, and which of those a human approves. An agent that can rank candidates and an agent that can reject them are not the same product, whatever the demo looks like. Irreversible actions get a human in the loop, and that human is named.

If someone challenges this outcome in six months, what does the log say? This is the question that catches what the other three miss, because it is answered by the system rather than by the team. Read a real log line out loud. If it names a person for something a machine did, the permission model is already wrong and no policy document will fix it after the fact.

Closing

The industry spent a year arguing about whether a thing is really an agent. It was a useful argument and I made my own contribution to it. But a system that acts is not defined only by whether it acts. It is defined by what it is allowed to reach when it does, and that boundary is being set right now, quietly, by whoever wired the first integration under deadline.

Taiwan is the loud version of the lesson. The quiet version is running in production somewhere in your company today, holding a human's token, doing exactly what it was asked, and writing that person's name into every row it touches. Nobody will notice until someone asks who decided. Build the second gate before the question arrives.

Sent when something new lands

Roughly twice a month. Nothing else. By subscribing you agree to the privacy policy.

Related

Want to talk about this?

Book a 30-min chat→