Authorisation stops at the wrong boundary

On agent identity, retrieval, and the question nobody is asking.

The enterprise identity industry spent the first half of 2026 arriving at a genuine consensus, and it is worth acknowledging how quickly it happened. At the European Identity Conference in Berlin, the chairman of the OpenID Foundation described AI agents as digital staff that plan, invoke tools and act — and argued that this breaks the existing assumptions of delegated authority, registration and accountability that enterprise identity was built on. Vendors at the same event converged on the position that the missing layer is runtime authorisation which evaluates every action rather than checking credentials once at the door. The Cloud Security Alliance published a whitepaper in May 2026 titled "The Non-Human Identity Governance Vacuum", observing that users of one major agent-building platform had collectively created more than a million agents, that non-human identities now outnumber human ones by a wide and poorly-measured margin, and that the identity infrastructure required to govern that population does not exist at most organisations while adversaries have already begun operationalising attacks against the gap. The architectural answer is now close to doctrine: an agent must be a first-class identity of its own — cryptographically attested, short-lived, minted at runtime, with the originating human preserved as the delegating subject through token exchange — because an agent running on a borrowed human credential makes every action forensically that person's action, inherits whatever access that person accumulated over a career, and can only be switched off by switching off the person. All of this is correct. All of it is about what an agent is permitted to do. And in a system where the agent's output is grounded in retrieved enterprise documents, the question that actually determines whether anything leaks is a different one, which almost nobody in this conversation is asking: what is the agent permitted to know?

This is the seventeenth piece in a series I have been writing for neuland.ai. [¹] An earlier piece argued that containment in agentic systems has to work in both directions — that your agents must not get out and other people's must not get in. [²] The most recent argued that when sovereignty of location commoditises, what remains defensible includes the authorisation model, and asserted in passing that a serious platform reduces the retrieval space to the requesting identity's rights before the model reasons rather than filtering afterwards. [³] That assertion deserves to be demonstrated rather than claimed, because it is the single most consequential design decision in a permission-aware AI system and the industry is currently building the other way.

The convergence, and where it stops

The consensus on agent identity is sound and I do not want to undersell it. The three-party distinction that has emerged in the practitioner literature is genuinely useful: the requester who initiated the work, the agent responsible for planning and coordinating it, and the executor — the tool, model or sub-agent performing a specific operation. These must stay connected without being merged, because a shared downstream account hides which agent acted and under whose authority. [⁴]

The insight underneath it is sharper still. A traditional service account has standing identity and standing scope; it exists for a defined purpose. An agent has variable scope per task — the same agent acts for different people at different moments, with different entitlements, inside different delegation chains. [⁵] So a one-time login cannot establish that the agent remained within its approved purpose for the duration of a workflow, which is why authorisation has to be evaluated continuously rather than granted once. And the corollary that regulated institutions should read twice: permission to view a customer record does not imply permission to export it, modify it, forward it to another system, or delegate access to it. [⁶]

All of this concerns actions. Tool invocations, writes, sends, escalations, delegations. The policy enforcement point sits between the agent's intent and the effect it wants to have on the world, and it asks: may this identity, right now, perform this operation?

That is a necessary question. It is not sufficient, and the reason is specific to how these systems actually produce answers.

The question the action-authorisation model cannot ask

Consider what happens when an employee asks an assistant a question about their own organisation. The system embeds the query, searches a corpus that spans file shares, mail, a document management system and several line-of-business applications, retrieves the passages that are semantically closest, and passes them into the model as context. The model reasons over that context and produces an answer with citations.

Now suppose the corpus contains a document this particular employee is not entitled to see — a personnel file, a draft restructuring plan, a legal opinion on a live dispute, the commercial terms of a supplier contract negotiated by a different division.

The action-authorisation model has nothing to say about this. No prohibited operation has occurred. The agent performed a retrieval it was entitled to perform, on a corpus it was entitled to query, using an identity that was properly minted and correctly delegated. Every runtime check passes. And the confidential document is now inside the model's context window.

The common answer is to filter the output: check entitlements against whatever the model produced, redact or suppress anything the user should not receive. This is where a great many enterprise AI deployments currently sit, and it fails for five separate reasons that compound.

The unauthorised material entered the context, which means it influenced the generated tokens whether or not it was quoted. It shaped the reasoning — an answer that reflects knowledge of a confidential restructuring plan is a disclosure even when it names nothing. It is in the logs, because a system with a proper audit trail records what was retrieved, and the audit trail is now itself a confidentiality problem. It is reachable by indirection, because a filter that catches quotation does not catch inference, and a sufficiently patient user does not need the document quoted. And most seriously: you cannot prove the negative. Asked by an auditor whether an employee could have obtained information from a document they were not cleared for, the honest answer from a post-filtering architecture is that the document was retrieved, was processed, and the filter is believed to have worked.

For a supervised institution that is not an answer. Under the audit and traceability obligations that became broadly applicable with the EU AI Act on 2 August 2026, "the filter is believed to have worked" is not a control. [⁷]

Authorising the retrieval instead

The alternative is to move the check earlier, so that entitlement is enforced on the search space rather than on the output.

The requesting identity arrives with the query. Before any retrieval executes, the searchable space is reduced to exactly the material that identity is entitled to see. The vector search, the lexical search and the reranking then all operate on that reduced space. The consequence is worth stating precisely: for that query, the unauthorised document does not exist. It is not retrieved, so it does not enter the context, so it cannot influence the reasoning, so it does not appear in the audit trail, so it cannot be reached by indirection — and the answer to the auditor's question becomes structural rather than probabilistic. The document was not filtered out. It was never in scope.

The guarantee is a single sentence and it has to hold identically in four cases: a human asking directly, a long-running session, an autonomous agent acting on that human's behalf, and an agent arriving from another platform under a delegated identity. What the requesting identity may not see, the system cannot output — because it was never retrieved.

Three things are required to make that true, and none of them is free.

An authoritative permission record that is separate from the meaning layer. This is the part most architectures get wrong, and the reason is understandable. A vector index optimised for approximate similarity search at scale is the wrong place to hold the authoritative answer to who may see what. Approximate is exactly the wrong property for an access decision. So the permission record belongs in a deliberately unexciting transactional store — one an auditor can read, query and understand, with no probabilistic component anywhere in it — kept structurally separate from the layer that holds semantic representations. One plane is the system of record for entitlements. The other is the system of meaning. Neither should attempt the other's job.

Relationships rather than roles. Role-based access control answers who are you. Retrieval authorisation needs to answer may you see this specific object, right now, in this context — which is a question about the relationship between an identity and an object, evaluated per request. It also has to accommodate the case that role-based models structurally cannot: a sub-agent spawned mid-task, whose identity did not exist when the parent workflow started and therefore could not have been provisioned in advance. A relationship-based model expresses this natively, because the delegation chain is itself a set of relationships and the entitlement of a runtime-minted sub-agent is derivable from the chain that created it.

Propagation, honestly accounted for. Here is the cost. When an entitlement changes — someone leaves a project, a document is reclassified, a retention period expires, a legal hold lands — that change must reach both planes. It has to be applied when content is ingested and re-evaluated when a query executes, because between those two moments the world moves. Deletion is worse: a document removed from a source system has to disappear from the record, from the semantic index, and from anything derived from it. This is real engineering work with real failure modes, it consumes part of the latency budget on every query, and any vendor who tells you it is a configuration toggle has not built it. The correct claim is not that the cost is small. It is that the cost is worth paying, because the alternative is an architecture that cannot answer an auditor's question.

Why this is the harder half

There is a reason the industry converged on action authorisation first, and it is not incompetence.

Action authorisation is a well-understood problem with mature standards. There is a request, a policy, a decision point, and an outcome that is either permitted or refused. The identity industry has been building this for twenty years, and adapting it to agents — short-lived credentials, token exchange, delegation chains — is genuinely difficult but it is difficult in a familiar direction. The practitioner assessment from Berlin was that the agentic identity conversation currently sits roughly where passkeys did a few years ago: the problem is clearly stated, the standards are forming, and production case studies are thin. [⁸] That is a fair description of a field making real progress.

Retrieval authorisation is harder for a structural reason. It cannot be added as a layer. A policy enforcement point can be placed in front of a tool call because the tool call is a discrete event with a boundary. Retrieval has no equivalent boundary — the entitlement has to be inside the query, shaping which candidates are even considered, which means the authorisation model and the search architecture have to be designed together. A system that was built to retrieve first and filter afterwards cannot be retrofitted into one that trims first, because the trim requires an authoritative entitlement record that is queryable at retrieval latency, and if that record does not exist in the right shape it has to be built from scratch.

Which is the argument this series has been making in one form or another since February: the properties that matter in enterprise AI are properties of the architecture, not features on top of it. Compliance is a system property. Containment is a system property. Authorisation of what a system may know is a system property, and it is decided at design time or not at all.

Where neuland.ai stands

The neuland.ai HUB enforces entitlement on the search space before the model reasons. The authoritative record of who may see what is held in a transactional store with no probabilistic component, deliberately separate from the layer that holds semantic representations, and readable by an auditor without interpretation. Entitlements are expressed as relationships rather than roles, which allows a sub-agent minted at runtime to inherit a derivable scope from its delegation chain rather than requiring an identity that was provisioned in advance. Permission and deletion changes are applied at ingestion and re-evaluated at query time. The same guarantee applies whether the requester is a person, a session, an agent, or an agent arriving across a platform boundary under a delegated identity — which is what makes platform-to-platform coupling possible without exporting the customer's access control model along with the query. Every retrieval and every decision is recorded on an append-only trail, so that the question of what a given identity could have seen at a given moment has an answer that does not depend on trusting a filter. [⁹]

The research effort behind this is systems and infrastructure work rather than model research, and the honest framing of it is that the difficult part was never the concept. Trimming a search space to an entitlement set is not a novel idea. The difficulty is doing it at retrieval latency, over a corpus large enough to matter, across source systems whose own permission models disagree with each other, while keeping two planes consistent under continuous change — and then proving it to an auditor. That is unglamorous engineering and it is most of the work.

Personal take

The identity industry is going to solve agent authentication and action authorisation, probably within about two years, and it will be a genuine achievement. Standards are forming, the vendors are serious, and the direction is right.

What worries me is that a great many enterprises will read that progress as completion. They will mint proper agent identities, implement runtime authorisation on tool calls, produce an impressive policy architecture — and still be running retrieval that reaches the entire corpus and filters the output, because nothing in the agent identity conversation told them that was a problem. They will pass a security review and remain unable to answer the only question a regulator will actually ask, which is not what did your system do but what could this person have learned.

The distinction is easy to state and expensive to retrofit. An agent that is properly identified, correctly scoped, continuously authorised and fully audited can still tell a user something they were never entitled to know, if the retrieval that grounded its answer was not itself constrained by that user's rights. Identity establishes who is acting. Action authorisation establishes what they may do. Neither establishes what they may know, and in a retrieval-grounded system that is where confidentiality actually lives.

A brief note on the regulatory backdrop, since it continues to develop. The EU AI Act became broadly applicable on 2 August 2026, with GPAI enforcement powers under Chapter V binding from that date; the Digital Omnibus agreement of 7 May 2026 postponed the high-risk Annex III obligations to 2 December 2027 and Annex I obligations to 2 August 2028. [¹⁰] Audit and traceability expectations for AI-initiated activity have moved from good practice toward legal requirement, and an architecture that can only demonstrate that a filter was applied is on the wrong side of that shift.

Authorisation stops at the wrong boundary. Moving it earlier is the work in front of us, and it is the work we have been doing.

¹ Series articles at neuland.ai: Zentrale Plattform für Enterprise-KI .

² See the earlier piece in this series on containment as a bidirectional system property.

³ See the previous piece in this series on the commoditisation of sovereignty of location and the four properties that remain defensible.

⁴ The requester / agent / executor distinction, and the requirement that the three remain connected without being merged, as set out in enterprise agent identity guidance published through 2026. The failure mode described — a shared downstream account obscuring which agent acted and under whose authority — is widely documented in that literature.

⁵ On the distinction between a traditional service account (standing identity, standing scope, defined purpose) and an agent (variable scope per task, acting for different principals at different moments inside different delegation chains), see enterprise agentic authentication references published in mid-2026.

⁶ The observation that permission to view a record does not imply permission to export, modify, forward or delegate access to it appears consistently across 2026 agent identity guidance and is the point most frequently lost in implementation.

⁷ EU AI Act broadly applicable from 2 August 2026. Practitioner commentary published in June 2026 noted that audit capability for AI-initiated activity was moving from best practice toward legal requirement as that date approached.

⁸ Practitioner assessment from the European Identity Conference, Berlin, mid-2026: the agentic identity conversation was characterised as sitting roughly where passkeys did several years earlier — problem clearly stated, standards forming, production case studies not yet available. Also from that event: the OpenID Foundation chairman's framing of agents as digital staff that plan, invoke tools and act, breaking existing assumptions about delegated authority, registration and accountability; and the argument that the missing layer is runtime authorisation evaluating every action rather than credentials checked once. Cloud Security Alliance, "The Non-Human Identity Governance Vacuum", 20 May 2026, on the scale of agent creation on major platforms, the ratio of non-human to human identities, and the absence of adequate governance infrastructure.

⁹ neuland.ai HUB authorisation architecture: entitlement enforced on the retrieval space ahead of reasoning; authoritative permission record held in a transactional store separate from the semantic layer; relationship-based entitlement model supporting runtime-minted sub-agent identities with scope derivable from the delegation chain; permission and deletion changes applied at ingestion and re-evaluated at query time; identical guarantee across human, session, agent and cross-platform delegated requests; append-only audit trail covering retrieval and access decisions. neuland.ai AG retains responsibility for content quality and clean delivery of results across all customer engagements.

¹⁰ Council of the EU and European Parliament provisional political agreement on the Digital Omnibus on AI, 7 May 2026: Annex III high-risk obligations postponed to 2 December 2027; Annex I obligations postponed to 2 August 2028; Article 50(2) watermarking obligations moved to 2 December 2026. GPAI enforcement powers under Chapter V binding from 2 August 2026.

Image generated using the neuland.ai HUB.