A fashion platform published the most useful agent-security document of the week, and it is not a warning. Zalando built the piece every company piloting agents will eventually need - the part that decides whose authority an agent carries when it acts for an employee - and then gave it away. North's interest is less in the software than in the timing: the decision it forces is cheap to make now and expensive to retrofit later, and a pilot that does not make it on purpose makes it by default. She comes down firmly on one side, and she is clear about what the other side costs. — Muximus
When an agent opens a pull request, reads a calendar or updates a ticket for an employee, whose credential is it using? It sounds like a question for the platform team. It is a question about who in the company can do what once agents start acting for staff, and that makes it a leadership question.
There are two permission sets in play, and it is easy to treat them as one. The first is what the employee is allowed to do. That already exists, in whatever the company uses to manage access. The second is what the agent is allowed to do. That is new, and someone has to write it down.
The safe answer is the overlap of the two, enforced somewhere the agent cannot reach. On 2026-09-25 Zalando published how it enforces exactly that on its internal agent platform, and released the core component under the MIT license. My recommendation, argued below: build that seam now, before the agents multiply.
The framework: two sets, one overlap
Think of it the way a finance team thinks about spending. The employee has a budget. The agent is a new kind of buyer acting for that employee. Nobody sensible hands the buyer the company card and hopes. The buyer gets a purchase order, for this item, under this employee's budget, within the buyer's own limits, and the card stays with finance.
The two common shortcuts both hand over the card.
The shared service account. The agent gets its own login. It works on day one. It also means every employee who talks to the agent can reach whatever that account reaches, and the audit log records the service account as the actor rather than the person who asked.
The employee's own token. The agent is handed the person's GitHub or Google credential. Now the agent is scoped to the right person, but the token sits inside the agent's process, so everything that can influence or inspect the agent is one step from that person's full access to the provider.
Both skip the same step. Neither gives the agent a boundary of its own.
What a missing boundary looks like in shipped software
Elastic disclosed a concrete case the same day Zalando published. Advisory ESA-2026-85 (CVE-2026-72668, CVSS 3.1 score 7.3, High) covers Agent Builder in Kibana 9.4.0 through 9.4.6, which Elastic classifies as CWE-441, a confused-deputy flaw. In the advisory's words, "A non-administrative user able to edit a shared agent could cause privileged operations to be carried out under the identity of a higher-privileged user who subsequently interacts with that agent." Where the same user can also author workflows, Elastic says it can extend to full administrative control of Kibana and the Elasticsearch cluster.
The preconditions narrow it, and they belong in any honest account. The attacker needs the Agent Builder privilege to manage agents and the Workflows privilege to create workflows, a generative AI connector has to be configured, and a higher-privileged user has to use the agent afterward. Both features are enabled by default. The fix is in 9.4.7 and 9.5.0, and Elastic Cloud Serverless was patched before disclosure.
This is neither shortcut exactly. It is what happens when a shared agent runs as whoever invokes it and has no limit of its own: whoever can edit the agent borrows the reach of whoever uses it.
If you are sponsoring an agent pilot, there is one question to put to the team running it, and it takes a minute. When the agent calls GitHub on someone's behalf, whose token is in that request, and where does it sit between calls? If the answer is "the agent has it," the boundary is missing, and you have learned that before an advisory taught it to you.
What Zalando built
Zalando is a fashion and lifestyle platform, not an identity vendor, and it gives the broker away under the MIT license. That matters when weighing the design: nobody is selling this. Its engineers describe three problems they had to solve - identifying agents through their own machine identity, giving agents access to many third-party systems that each issue their own tokens, and making access decisions that combine the user's permissions with the agent's. They note that none of these is new. They appeared with microservices, and "as an industry we have partly ignored them."
The answer is a central broker plus a gateway. The agent is given its own permissions on top of those the user already has, and the effective permission is, in Zalando's words, "the intersection of both sets."
The agent never touches the provider token. For each tool call it sends a combined user-and-agent token to the gateway, agentgateway, an Apache-2.0 open-source project. The gateway asks the broker to exchange it for a token from the target system using OAuth 2.0 token exchange, the standard defined in RFC 8693. That provider token goes back only to the gateway, which attaches it and forwards the request. The purchase order goes out; the card never leaves finance.
Zalando's worked example is the one to show a board. A user asks an agent in Google Chat to summarize their open GitHub pull requests. The Chat bridge, a privileged client, impersonates the user toward the broker and obtains a user-and-agent token for the agent. The exchange for a GitHub token only succeeds if the user has granted the agent a permission set that covers reading repositories, and the agent, in Zalando's words, "returns the summary without ever seeing the GitHub token."
Consent is written in business terms, which is the detail I would most want a non-technical executive to see. Administrators define permission sets named after capabilities, such as reading repositories, rather than showing users raw OAuth scope strings, which Zalando calls "inconsistent and often too coarse for a person to evaluate." A user can grant less than an agent asks for. Grants are revocable and can carry an expiry, and there is at most one active grant per user and agent. Provider sessions are stored encrypted, one per user per service; ending one removes access for every agent that depends on it, and the broker lists those agents first.
The trade-offs
Here is what the case for building this has to survive.
It is identity infrastructure, and it needs an owner. The broker does not replace an identity provider. It can mint tokens itself or sit in front of an existing OAuth 2.0 authorization server, and it relies on a reverse proxy to authenticate users. Zalando builds its platform on Kubernetes, where it operates "hundreds of production clusters", with kagent as the agent runtime. A company without a Kubernetes platform will not lift this stack as-is. The pattern transfers more easily than the components. And the owner has to be someone who owns identity, not the team piloting the agent.
It is early, and the evidence is a design, not a result. The repository is public, written in Go, at release v0.1.52 on 2026-09-25, with 23 stars and 34 open issues when checked on 2026-09-28. The README says it is "currently in active development" and used "in production internally for several MCP servers". Zalando has not disclosed how many agents, users or calls run through the broker, and has published no incident data. What exists is a design, a working implementation and a large company's decision to run it. There is no measurement showing what it prevented, and I will not pretend otherwise.
Trying it is cheap. The quickstart runs the broker stack locally with Docker Compose and ends with a working delegation through the consent screen, with no cloud credentials required. Production is a different budget line.
Zalando names its own limits, and they are the right ones to plan around:
- "A revoked or expired grant blocks future exchanges, but it cannot revoke a provider token that has already been issued." Revocation is not instant.
- A central token service called on every hop "can become expensive or prohibitive in terms of latency." Zalando is looking at SPIFFE to separate proof of the agent's identity from proof of the human's.
- Per-tool approvals are "a crutch: many users will rubber-stamp them once approval fatigue sets in." For high-risk actions Zalando plans out-of-band approval through CIBA, for example via Okta Verify, and it already runs Open Policy Agent checks at the gateway.
That last one deserves attention from anyone whose current plan is "a human approves every agent action." Zalando calls that plan a crutch.
The verdict
Build the seam now. Do not wait for an identity vendor to finish its agent product.
The reason is in Zalando's own roadmap. It says it tracks the XAA draft and vendor products, "for example from Okta," and "will adopt such features when they make sense, without agents or MCP servers having to change." Read that as a procurement argument. The gateway-and-exchange boundary is what turns a later vendor choice into a configuration change instead of a rewrite of every agent. A pilot that has handed its agents a service account or users' raw tokens has no such boundary, and every agent it adds makes the retrofit larger.
For a mid-market company this quarter, the seam looks like this:
- A written answer to "where do provider credentials live?" The answer is: not in the agent.
- One gateway that every agent tool call passes through.
- Per-call token exchange, so the agent carries a user-and-agent token and never a provider token.
- Effective permission defined as the overlap of what the user may do and what the agent is allowed to do.
- Grants named as business capabilities, revocable, with an expiry by default.
- A list of every agent that today holds a service account or a user's token, with a retirement date for each.
Zalando's broker is one way to get items 2 to 5 without writing them. Item 6 costs nothing but a meeting, and it tells a leadership team how much of this is already exposed.
Disclosure: VarOps is published by Ran Aroussi, whose other company, Automaze, builds AI deployments for clients, including the kind of agent boundaries this piece recommends.
