Agentic Engineering · Brennenstuhl on Security

How does authorization work for MCP servers?

Tue, 13 Oct 2026 00:00:00 +0200

Short answer: In the MCP authorization specification (revision 2026-07-28), a protected MCP server over HTTP is an OAuth 2.1 resource server: it publishes Protected Resource Metadata that points clients to its authorization server and accepts only tokens issued for itself. MCP clients discover that authorization server, run the authorization code flow with PKCE, and name the MCP server in a resource parameter on every authorization and token request.

This entry describes the Model Context Protocol (MCP) authorization specification as of revision 2026-07-28, which the MCP versioning page listed as the current revision on 13 October 2026. Later revisions may change these requirements.

Key findings #

As of MCP revision 2026-07-28, MCP servers must implement OAuth 2.0 Protected Resource Metadata (RFC 9728), and MCP clients must use it to discover the authorization server.

Source: Model Context Protocol, Authorization, revision 2026-07-28

Link to this finding Save as image (PNG, 1200 by 630 pixels)

MCP clients must send the RFC 8707 resource parameter with the MCP server’s canonical URI in both authorization and token requests, whether or not the authorization server supports it.

Source: Model Context Protocol, Authorization, revision 2026-07-28

Link to this finding Save as image (PNG, 1200 by 630 pixels)

MCP servers must validate that an access token was issued specifically for them as the intended audience and must not accept or transit any other tokens.

Source: Model Context Protocol, Authorization, revision 2026-07-28

Link to this finding Save as image (PNG, 1200 by 630 pixels)

An MCP server that calls upstream APIs must use a separate token from the upstream authorization server and must not pass through the token it received from the MCP client.

Source: Model Context Protocol, Authorization Security Considerations, revision 2026-07-28

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Primary sources on MCP authorization
Study	Year	Sample	Method	Finding
Model Context Protocol: Authorization (revision 2026-07-28)Model Context Protocol	2026	n/a	Specification	Defines roles, discovery, the authorization flow, the resource parameter, token handling and step-up authorization for HTTP transports.
Model Context Protocol: Authorization Security Considerations (revision 2026-07-28)Model Context Protocol	2026	n/a	Specification	Requires audience binding, PKCE, exact redirect URI matching and a ban on token passthrough.
OAuth 2.0 Protected Resource Metadata (RFC 9728)IETF	2025	n/a	Specification	Defines the metadata document and the WWW-Authenticate parameter that point a client to a resource’s authorization servers.
Resource Indicators for OAuth 2.0 (RFC 8707)IETF	2020	n/a	Specification	Defines the resource parameter and asks authorization servers to audience-restrict tokens to it.
Economies of Scale for MCP and Agentsthis site	2026	n/a	Talk	States that an agent should not hold a shared, long-lived provider credential and presents the broker’s delegation model.

What to do #

For engineers #

For an MCP server over HTTP, publish Protected Resource Metadata, answer unauthenticated requests with a 401 that points to it, and check the audience of every token. Put the scopes an operation needs in the WWW-Authenticate challenge, all at once. If the server calls other APIs, get its own token for each of them. The token exchange entry shows one way to do that.

For an MCP client, implement both discovery mechanisms, PKCE with S256, the resource parameter, and the issuer check. Never put tokens in the query string.

An MCP server on the STDIO transport is outside this specification, which says such servers should take credentials from the environment. Keep those credentials short-lived and task-scoped, as my AppSec essay recommends for coding agents.

For product and UX #

Start with the minimal scopes and ask for more only when an operation needs them. The specification warns that misconfigured scopes may require frequent user interaction, and that challenging one scope at a time forces several authorization round-trips for one operation.

How it works #

The specification defines 3 roles. The MCP server is an OAuth 2.1 resource server, the MCP client is an OAuth 2.1 client acting for a resource owner, and the authorization server issues the tokens. Authorization is optional for MCP implementations. Implementations on HTTP-based transports should conform to the specification, and STDIO implementations should not.

A first connection follows these steps:

The client sends an MCP request without a token. The server answers with HTTP 401 and a WWW-Authenticate header that carries the resource_metadata URL from RFC 9728 and, as the specification recommends, the required scope.
The client fetches the Protected Resource Metadata and picks an authorization server from it. It then reads that server’s metadata through OAuth 2.0 Authorization Server Metadata (RFC 8414) or OpenID Connect Discovery. Clients must support both, and if the metadata doesn’t list code_challenge_methods_supported, the client must refuse to proceed.
The client gets a client ID. It uses pre-registered client information if it has some, then Client ID Metadata Documents if the authorization server supports them. Dynamic Client Registration is deprecated and kept only as a fallback for backwards compatibility.
The client starts the authorization code flow with PKCE, the resource parameter and the selected scopes, and records the expected issuer. When the response comes back, it validates the iss parameter (RFC 9207) before it redeems the code.
The client redeems the code with the code_verifier and the resource parameter, then sends the access token in the Authorization: Bearer header on every request.

When a token lacks a scope at runtime, the server answers with 403 and error="insufficient_scope". The client then runs a step-up flow with the union of its previous scopes and the new ones.

Revision 2026-07-28 doesn’t cover token exchange in its core authorization pages. Optional authorization extensions live in a separate repository. In the Agentic Identity Broker, which Magnus Jungsbluth and I built, an MCP gateway exchanges the agent’s token for the matching provider token through RFC 8693, so the provider token never reaches the agent. I describe that design in the retrospective, and we presented it in our AGNTCon + MCPCon talk.

How should people grant and revoke an agent's access?

Tue, 13 Oct 2026 00:00:00 +0200

Short answer: Let people grant each agent access per service, with a permission set they choose and an expiry, and let them revoke that grant at any time. Revoking the grant has to stop every token derived from it, so keep issued tokens short-lived and check the grant whenever a new token is issued.

Key findings #

In the Agentic Identity Broker, a user grants an agent access to a service with a chosen permission set and an optional expiry, and can revoke that grant at any time.

Source: What I Learned Building an Identity Broker With Coding Agents (janbrennenstuhl.eu, 2026)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Under RFC 7009, revoking a refresh token should also invalidate all access tokens based on the same authorization grant if the authorization server supports access token revocation.

Source: RFC 7009, OAuth 2.0 Token Revocation (IETF, 2013), Section 2.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Immediate revocation of self-contained access tokens needs backend coordination that RFC 7009 calls non-standardized, and short-lived access tokens limit how long a revoked token stays in use.

Source: RFC 7009, OAuth 2.0 Token Revocation (IETF, 2013), Section 3

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Primary sources on agent consent and revocation
Study	Year	Sample	Method	Finding
OAuth 2.0 Token Revocation (RFC 7009)IETF	2013	n/a	Specification	Defines a revocation endpoint and how revoking one token can revoke related tokens and the grant.
Best Current Practice for OAuth 2.0 Security (RFC 9700)IETF	2025	n/a	Specification	Binds refresh tokens to the consented scope and resources and lets them expire after inactivity.
Resource Indicators for OAuth 2.0 (RFC 8707)IETF	2020	n/a	Specification	Lets the authorization server tell the user which resources a client will access on their behalf.
OAuth 2.0 Token Exchange (RFC 8693)IETF	2020	n/a	Specification	Leaves revocation of tokens issued by an exchange to the implementation.
Model Context Protocol: Authorization (revision 2026-07-28)Model Context Protocol	2026	n/a	Specification	Asks clients to request minimal scopes first and add scopes through step-up authorization.
What I Learned Building an Identity Broker With Coding Agentsthis site	2026	n/a	Field report	Describes per-agent grants with chosen permissions, optional expiry and revocation at any time.

What to do #

For engineers #

Model the grant as a record of its own that names the person, the agent, the service, the permissions and the expiry, and issue every token from it. Check that record whenever you issue or exchange a token, so a revocation takes effect at the next tool call. Expiring tokens are the fallback for tokens you can’t recall.

Wire revocation through every layer you control. Call the RFC 7009 revocation endpoint where the provider offers one, and don’t stop at the first token. RFC 8693 says tokens issued by a token exchange aren’t linked to their input token, so revoking one doesn’t reach the other unless you build that.

Ask for the least access first. The MCP authorization specification describes this as step-up authorization: request minimal scopes and add more when a server asks for them.

For product and UX #

Show each grant with the agent, the service, the permissions and the expiry in plain words, and put the revoke action next to it. Default to an expiry instead of open-ended access. When an agent needs more access, ask at that moment for that specific permission.

How it works #

Granting access in OAuth starts with an authorization request. The client names the access it wants in scope and, with RFC 8707, the resources in resource. RFC 8707 notes that the authorization server can use those resource values to inform the user about the resources the client will access on their behalf. The consent screen can then name the service, not only a list of scopes.

In the Agentic Identity Broker, which Magnus Jungsbluth and I built, a user grants an agent access to a service with a chosen permission set and an optional expiry. The broker keeps both the user and the agent in every authorization decision. I describe the design in the retrospective, and my AppSec essay argues for narrow, time-limited permissions that the user can revoke at any moment.

Revoking access in OAuth uses the revocation endpoint from RFC 7009. A client sends the token it wants revoked, and the server invalidates it and, depending on policy, related tokens and the grant itself. RFC 7009 gives 2 reasons this matters for people: it stops a grant from staying valid without the user’s knowledge, and revoked grants disappear from any list of grants the authorization server shows the user. The server answers with HTTP 200 even for an invalid token. A 503 means the client must assume the token still exists.

Self-contained tokens make revocation harder. A resource server can check a self-contained token, such as a JSON Web Token (JWT), without asking the authorization server, so it won’t learn about a revocation on its own. RFC 7009 names short-lived access tokens with refresh tokens as one alternative. RFC 9700 adds that refresh tokens must stay bound to the consented scope and resources, should expire after a period of inactivity, and may be revoked on security events such as a password change or logout.

How does OAuth 2.0 Token Exchange keep provider tokens away from agents?

Tue, 13 Oct 2026 00:00:00 +0200

Short answer: OAuth 2.0 Token Exchange (RFC 8693) lets a client trade one token for another token meant for a specific target service. When a gateway runs that exchange on each tool call, as in the Agentic Identity Broker, the provider token stays between the broker, the gateway and the provider and never reaches the agent.

Key findings #

RFC 8693 lets a client present a security token to an OAuth 2.0 authorization server acting as a Security Token Service and receive a new token, for example one scoped more narrowly for a downstream service.

Source: RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020), Section 1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

In the Agentic Identity Broker, an MCP gateway exchanges the agent’s token for the matching provider token through RFC 8693 on each tool call, so the provider token never reaches the agent.

Source: What I Learned Building an Identity Broker With Coding Agents (janbrennenstuhl.eu, 2026)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

RFC 8693 warns that without client authentication at the token endpoint, anyone holding a compromised token can trade it for other tokens.

Source: RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020), Section 2.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

In a JWT issued through token exchange, access control decisions must consider only the top-level claims and the current actor named in the act claim, while nested prior actors are informational.

Source: RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020), Section 4.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

A token exchange creates no tight link between the input and output tokens, so passing revocation from one to the other depends on the implementation and isn’t a property of the protocol.

Source: RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020), Section 2.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Primary sources on token exchange for agents
Study	Year	Sample	Method	Finding
OAuth 2.0 Token Exchange (RFC 8693)IETF	2020	n/a	Specification	Defines the token exchange grant, its request and response parameters, and the act and may_act claims.
Resource Indicators for OAuth 2.0 (RFC 8707)IETF	2020	n/a	Specification	Defines the resource parameter that tells the authorization server where a token will be used.
What I Learned Building an Identity Broker With Coding Agentsthis site	2026	n/a	Field report	Describes how a gateway exchanges the agent’s token for the matching provider token on each tool call.
Economies of Scale for MCP and Agentsthis site	2026	n/a	Talk	Presents the broker’s delegation model at AGNTCon + MCPCon Europe 2026.

What to do #

For engineers #

Put the exchange in a component the agent can’t control, such as a gateway, and authenticate that component at the token endpoint. Name the target with resource or audience and ask for the smallest scope the tool call needs. RFC 8693 points out that broad requests across many target services are more likely to be refused.

Treat revocation as your own job. The RFC leaves it to the implementation whether revoking a grant or an input token affects tokens already issued, so keep issued tokens short-lived and check the grant at exchange time. Consent and revocation covers the rest.

If an agent’s token can travel further, use the act claim to record the agent as the actor and the may_act claim to state who may act for the subject.

For product and UX #

Users don’t see the exchange, but they see its effects. When a tool call fails because a grant expired or was revoked, tell the user which service and which agent were affected and how to grant access again.

How it works #

RFC 8693 defines the exchange as 1 request and 1 response at an authorization server’s token endpoint. With a gateway between an agent and its tools, the exchange runs like this:

Step through the exchange

The agent calls a tool through the gateway and presents its own token.
The gateway acts as the RFC 8693 client. It sends a POST to the token endpoint with grant_type=urn:ietf:params:oauth:grant-type:token-exchange, a subject_token that represents the person on whose behalf the request is made, and its subject_token_type. Optional parameters name the target (resource, audience), the access wanted (scope), and the token type wanted (requested_token_type).
The gateway authenticates with the normal OAuth 2.0 client authentication methods.
The authorization server validates the presented tokens and decides by policy whether to issue a token for the named target. If it refuses, it answers with invalid_request, or with invalid_target when it won’t issue a token for the requested target.
A successful response is a normal OAuth token response: access_token carries the issued token, together with issued_token_type, token_type, and, as recommended, expires_in. The issued token doesn’t have to be an OAuth access token.
The gateway calls the target service with the issued token and returns only the result to the agent.

The following request shows step 2 with placeholder hosts and tokens. It illustrates the RFC parameters and isn’t the broker’s API. I’ve left the values unencoded and added line breaks for readability; a real request URL-encodes the form body.

token-exchange.http

POST /token HTTP/1.1
Host: broker.example.com
Authorization: Basic <gateway client credentials>
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<token the agent presented>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&resource=https://api.provider.example/
&scope=<permissions the tool call needs>

The Agentic Identity Broker that Magnus Jungsbluth and I built uses this pattern, as I describe in the retrospective. A user grants an agent access to a service, such as GitHub, with a chosen permission set and an optional expiry, and the broker stores the provider tokens encrypted. On each tool call, an MCP gateway such as agentgateway exchanges the agent’s token for the matching provider token, so the provider token never reaches the agent.

RFC 8693 also defines an optional actor_token for the party that will act on behalf of the subject. In the issued JWT, the act claim can record that actor, and nested act claims record a chain of earlier actors. The broker roadmap lists token exchange for agent-to-agent calls as planned work.

Should an agent use a robot account or delegated access?

Tue, 13 Oct 2026 00:00:00 +0200

Short answer: When an agent acts for a person, give it delegated access that names both the person and the agent, with narrow scopes, an expiry, and a way to revoke it. A robot account shared by several people gives the agent their combined permissions and hides whose request was whose.

Key findings #

When several people share an agent that holds a robot account, the agent acts with the combined permissions of all its users, and nobody can tell whose request was whose.

Source: What I Learned Building an Identity Broker With Coding Agents (janbrennenstuhl.eu, 2026)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Under the delegation semantics of OAuth 2.0 Token Exchange, the acting party keeps its own identity, separate from the person whose rights it uses.

Source: RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020), Section 1.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

The OAuth 2.0 security best current practice says an access token’s privileges should be restricted to the minimum the use case requires, and the token should be audience-restricted to a specific resource server.

Source: RFC 9700, Best Current Practice for OAuth 2.0 Security (IETF, 2025), Section 2.3

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Coding agents should not hold persistent identity and access management (IAM) roles or long-lived API keys; an identity broker can issue short-lived, task-scoped credentials on demand instead.

Source: AppSec in the Age of Agentic Engineering (janbrennenstuhl.eu, 2026)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Primary sources on robot accounts and delegated agent access
Study	Year	Sample	Method	Finding
OAuth 2.0 Token Exchange (RFC 8693)IETF	2020	n/a	Specification	Defines delegation and impersonation semantics and the act claim that names the acting party.
Best Current Practice for OAuth 2.0 Security (RFC 9700)IETF	2025	n/a	Specification	Asks for least-privilege, audience-restricted tokens and warns when resource servers can’t tell client tokens from user tokens.
Model Context Protocol: Authorization (revision 2026-07-28)Model Context Protocol	2026	n/a	Specification	Treats clients acting for a user differently from clients acting on their own behalf.
What I Learned Building an Identity Broker With Coding Agentsthis site	2026	n/a	Field report	Explains why the Agentic Identity Broker keeps both the user and the agent in every authorization decision.
AppSec in the Age of Agentic Engineeringthis site	2026	n/a	Essay	Argues for short-lived, task-scoped credentials and user-revocable delegation for agents.

What to do #

For engineers #

Ask first whom the agent acts for. If it runs a job on its own behalf, a dedicated client with its own narrow permissions is a reasonable fit. The MCP authorization specification explicitly mentions such client_credentials clients. If it acts for a person, use a grant that names that person and that agent, and keep it narrow and short-lived as RFC 9700 asks.

Prefer delegation over impersonation. A delegated token can carry the agent as the actor next to the person as the subject, so a resource server and your logs can tell them apart. RFC 9700 also warns that a resource server that can’t distinguish tokens obtained with a person’s involvement from tokens a client obtained on its own may let that client reach the person’s resources.

Keep provider credentials out of the agent’s context. Token exchange shows how a gateway can do this on each tool call.

For product and UX #

Show people which agent holds access to which service, with what permissions and until when. Give them one place to revoke that access. If several people use the same agent, show each of them only the grants they made.

How it works #

With a robot account, the agent holds a long-lived credential for each MCP server or API it calls. In OAuth terms, that is closest to a client that gets tokens for itself, without a person in the flow. RFC 9700 quotes the JSON Web Token (JWT) profile for access tokens (RFC 9068): the sub claim of such a token should identify the client application, while a token obtained with a person’s involvement should identify that person. A robot account therefore can’t express who asked for an action. In my retrospective, I describe the consequences once several people share the agent: combined permissions, no attribution, and credentials within reach of anything that tricks the agent.

RFC 8693 describes 2 ways one party can use another’s rights. With impersonation, party A gets B’s rights and is indistinguishable from B in that context. With delegation, A keeps its own identity, and it’s explicitly understood that A acts for B. The RFC uses this exact phrase: “In a sense, A is an agent for B.” A token that carries both identities is a composite token. In a JWT, the act claim names the acting party.

The Agentic Identity Broker that Magnus Jungsbluth and I built applies delegation. A user grants an agent access to a service with a chosen permission set and an optional expiry and can revoke the grant at any time. The broker keeps both the user and the agent in every authorization decision. The essay and our AGNTCon + MCPCon talk explain the design, and the project page links the code.

This model covers agents that act for a person. For autonomous agents with no human in the loop, I wrote in the retrospective that every approach I know of is still brittle.

What I Learned Building an Identity Broker With Coding Agents

Thu, 24 Sep 2026 00:00:00 +0200

On 18 September 2026, Magnus Jungsbluth and I presented the Agentic Identity Broker at AGNTCon + MCPCon Europe in Amsterdam. We had published its source code under the MIT license 3 days earlier. The broker lets people in enterprise environments give an AI agent scoped, revocable access to services such as GitHub or Google without handing the agent their credentials.

Magnus is my mentor and the mastermind behind the broker, and I’ve been his sidekick since we started at the end of 2025. We built the broker with coding agents from the first prototype in January 2026, put the first Model Context Protocol (MCP) server behind it in production in March, and had the first users in April. Over those 10 months, I switched agent harnesses 6 times and worked with 9 models from Anthropic and OpenAI. What kept the project on track through all those changes was the spec work we did up front and the effort we put into verifying every change. Most of what I learned is about specs, tests, and review.

Why We Started With Agent Identity #

Around the end of 2025, new Claude Sonnet and Opus models pushed the hype around agents through the roof. From a platform and security perspective, Magnus and I could see where that would lead. Without central capabilities that come with guardrails, every team would connect its agents to tools in its own way, and cleaning that up later would be very difficult. So we set out to solve the hard parts first: agent identity and access to tools. As far as we could tell, no product covered this at the time.

The quickest way to connect an agent to a tool is a robot account, where the agent holds a long-lived credential for each MCP server or API it calls. That breaks down as soon as several people share the agent. The agent then acts with the combined permissions of all its users, nobody can tell whose request was whose, and anything that tricks the agent can reach for those credentials. I made the case for delegation and consent infrastructure from the AppSec side earlier this year.

The broker keeps both the user and the agent in every authorization decision. A user grants an agent access to a service with a chosen permission set and an optional expiry, and can revoke that grant at any time. The broker stores the provider tokens encrypted. On each tool call, an MCP gateway such as agentgateway exchanges the agent’s token for the matching provider token through OAuth 2.0 Token Exchange (RFC 8693), so the provider token never reaches the agent.

Magnus and I describe the platform around the broker and the reasoning behind its design in the post that announced the release, and our talk slides explain the delegation model. Alejandro Saucedo, who adopted the broker for his Kubernetes Agent Orchestration System (KAOS), covers the identity side in his series Agentic Security & Identity.

We Used Spec Kit From the First Day #

Magnus had already experimented with GitHub’s Spec Kit before we started, and he did most of the heavy upfront work on our constitution. With Spec Kit, a team writes its binding principles into a constitution. For each feature, an agent then drafts a specification, a technical plan, and a task list before it writes any code. A newer command, /speckit.converge, checks the implementation against all 3 and appends tasks for the gaps it finds. We run implement and converge in turns until converge reports no gaps.

The broker repository shows how much of this piled up in 10 months. As of 26 September, it holds 42 feature specs, 38 architecture decision records (ADRs), and a constitution with 13 principles at version 2.1.0. Among other things, the principles require that the broker fails closed and forbid custom cryptography. An AGENTS.md file at the root sends every agent to the constitution, the relevant ADRs, and more specific AGENTS.md files for each part of the code base.

All that setup cost time before the first feature existed, and it pays off every day now. Whether I start an agent on a feature or a new contributor does, the agent reads the same principles, decisions, and earlier specs.

To start a similar project today, I’d own the spec work myself, hand the building to agents, and put more agents on review than on writing.

Early Models Wrote Tests That Tested Nothing #

The models I used in the first months of 2026 failed mostly by inventing things I never asked for and claiming things that weren’t true. Tests were our biggest problem, and for code that holds other people’s credentials, a passing test suite has to mean something. In those months, I regularly got green test suites for broken behavior. Agents implemented tests halfway or wrote assertions that didn’t check anything. Magnus and I spent most of our time getting them to write proper tests.

The constitution records that fight. It requires red-green-refactor test-driven development (TDD), where every test fails before the implementation exists, and a 1:1 mapping from each spec to an end-to-end (E2E) test that covers a complete user flow. Its version history shows that we added the E2E principle later, extended it to browser tests for the frontend, and clarified the rules for the red phase twice.

As of 26 September, the public repository contains about 105,000 lines of Go test code and about 49,000 lines of Go production code, counting non-blank, non-comment lines. We didn’t plan that ratio. About a quarter of the test code is E2E tests, which the constitution requires for every spec. I still think the broker needs more tests. I’d love to have a performance test suite and dedicated compliance checks against the RFCs the broker implements. Right now my agents and I are working on the stability, structure, and run time of the existing suites.

I Wrote Skills for the Libraries the Models Didn’t Know #

The models’ knowledge of the less common libraries we use was really bad. The broker encrypts tokens before storing them with the Go releases of the AWS Encryption SDK and the AWS Cryptographic Material Providers Library, and Claude failed hard at wiring them together. So I wrote a dedicated skill that the agent loads when a task touches encryption. The skill explains how the pieces fit together, includes a reference and complete examples, and tells the agent never to answer from its training data alone. I still make the cryptography decisions myself.

The repository holds a second skill of this kind for version 4 of jwx, the library the broker uses for JSON Web Tokens (JWTs). It tells the agent where to look up the current API before it answers, because earlier versions of that library have a different API.

Why I Switched Harnesses 6 Times #

For the first 4 months, I used Claude Code, mostly with Sonnet 4.5 and 4.6 and some Opus 4.6 on the side. It felt too heavy and talkative for me, so I moved to Pi and spent 2 months customizing it. With Pi, I switched from Claude models to GPT-5.4, then GPT-5.5 and GPT-5.6 Terra. After that, I went back and forth between Pi and oh-my-pi (OMP), an opinionated fork of Pi, for about a month. The full sequence was Claude Code, Pi, OMP, Pi, OMP, Pi, and finally OMP, which has been my only harness for the last 2 months. Since we published the broker, I’ve worked with GPT-6 Sol, GPT-6 Astra, and Claude Fable 5.1, and the agents got better with each step.

Most switches came down to harness details. Early OMP felt more autonomous and proactive than Pi, which I didn’t always want. In Pi, I really liked the pi-lens extension’s support for Opengrep, an open-source static analysis engine. OMP is much better nowadays, although I still fight with its advisor, a second model that reads every turn of the main agent and adds notes. I regularly turn the advisor off and (a few days later) on again. I talked about my setup in more detail on the Beyond Vibe Coding podcast in August.

What the agents knew about the project never depended on the harness, because the constitution, the specs, the ADRs, the AGENTS.md files, and the skills live in the repository.

Anyone starting now should pick a strong harness with good tool support, such as documentation lookup through Context7 or web search through Exa, and shouldn’t shy away from frontier models. I found them worth every penny for the broker.

Review Takes More Agents Than Writing #

For the release on 15 September, I squashed the private history into a single public commit. Agents helped remove internal references, build the documentation site, and run security reviews, while I worked on our OpenSSF Scorecard results (the Open Source Security Foundation’s automated checks of a repository’s security practices), designed the wordmark logo, and set up the domain’s DNS.

In the first 10 days after the release (15 to 24 September), the repository received 93 pull requests: 51 from me, 7 from Magnus, 26 from Dependabot (GitHub’s dependency update bot), and 9 from additional 2 contributors, Alejandro Saucedo and Farasath Ahamed. We merged 58 of them by 24 September.

Nowadays, some agents are always working on the broker. They harden security, improve the test suites and continuous integration (CI), prepare and implement specs for new features, and review changes. Each agent works in its own git worktree, so parallel agents don’t overwrite each other’s changes. I try to keep it to 2 or 3 agents at a time, but depending on the day and my meeting schedule, it can be 6 to 8. I start most of them myself.

Reviewing is the hard part. Early on, I expected roborev, a local daemon that reviews each commit in the background, to be a great addition to my harness, and I used it extensively. It regularly got lost in endless loops where it fixed and discussed the same or similar issues again and again. Over time it produced more noise and distraction than help. As the models got better and the harnesses got stronger, I left it behind and replaced it with custom review skills in my harness.

The architecture review agent in the repository is one example. It reads the constitution, the ADRs, and the port interfaces from the base branch, so a pull request can’t rewrite the rules we judge it by. It defaults to skepticism and looks for what agent-written pull requests tend to do: introduce a parallel mechanism instead of extending an existing one, add domain services that only delegate to repositories, and label tests as end-to-end when they cover a single segment of a flow.

Today I regularly have more agents reviewing in parallel than writing code. The README promises that we review every pull request. Agents review the code, and I still review the specs and the E2E tests myself.

What We Haven’t Solved Yet #

The broker solves cases where an agent acts on behalf of a human. Autonomous agents are harder: when no human is in the loop and machines or other agents call internal and external tools such as MCP servers, every approach I know of is still brittle. Central tool approvals are in the works, and the roadmap lists token exchange for agent-to-agent calls, intent-based authorization, and user-facing activity logs.

AGNTCon left me with the impression that the whole industry is still working on the same questions, and the standards are still catching up. Christian Posta from Solo.io gave a talk titled “What IS an Agent’s Identity?”, and the Identity Assertion JWT Authorization Grant (ID-JAG) talk by Aaron Parecki from Okta, Paul Carleton from Anthropic, and Joey Orlando from Archestra.AI named adoption by software-as-a-service (SaaS) providers as the missing piece. Some vendors already position early products, while working groups are still writing the underlying specs.

If you want to try the broker, point your coding agent at the repository and ask it how the broker would fit your setup, or run the local stack and walk through a delegation yourself. Please report vulnerabilities through the process on the security page. If you want to exchange ideas on approaches or features, open an issue or reach out to me directly.

Economies of Scale for MCP and Agents

Fri, 18 Sep 2026 00:00:00 +0200

Presented by Magnus Jungsbluth and Jan Brennenstuhl at AGNTCon + MCPCon Europe in Amsterdam on 18 September 2026.

Materials #

Reading companion #

An agent should not hold a shared, long-lived provider credential. The broker ties delegated access to both the person and the agent, with chosen permissions and optional expiry. On a tool call, a gateway exchanges the agent’s token for a provider token; the provider token does not enter the agent’s context.

This is a short reading companion, not a transcript. The supporting article explains the identity model and the engineering lessons in accessible HTML.

Agentic Identity Broker

Tue, 15 Sep 2026 00:00:00 +0200

Magnus Jungsbluth and I built the open-source Agentic Identity Broker. It keeps the user and the agent in authorization decisions and stores provider tokens outside the agent’s context.

Explore the project #

The project is licensed under MIT. This page reflects the September 2026 release; consult the project documentation for current capabilities.

AppSec in the Age of Agentic Engineering

Fri, 03 Jul 2026 00:00:00 +0200

Guest lecture by Jan Brennenstuhl for the cybersecurity course at Hochschule für Technik und Wirtschaft Berlin (HTW), summer term 2026.

Materials #

Reading companion #

Coding agents write a growing share of production code, so security feedback that arrives after the code exists cannot keep up. The lecture argues that AppSec teams get the most leverage from the harness the agent runs in: the rules, tools, sandboxes and credentials around the model, not the model itself. Three practices follow: deliver security findings while the task is still in the agent’s context, run agent tasks in disposable sandboxes with short-lived task-scoped credentials, and measure risk per change instead of per release.

This is a short reading companion, not a transcript. The supporting essay is the condensed lecture with context and references in accessible HTML.

Guest Lecture at HTW Berlin: AppSec in the Age of Agentic Engineering

Fri, 03 Jul 2026 00:00:00 +0200

I recently gave a guest lecture to the cybersecurity course at Hochschule für Technik und Wirtschaft Berlin (HTW). The topic was application security (AppSec) in the age of agentic engineering, and how coding agents change the daily work of developers and AppSec teams.

My central argument: AppSec teams have to move from finding problems after code is written to shaping the systems that coding agents write code inside. Agentic engineering makes weak defaults, slow handoffs, and local exceptions more expensive, so the biggest wins now come from the harness, the platform, and the risk model.

The full slide deck contains the key points, examples, and references from the session. Below is a condensed version of the lecture with some additional context and links.

Fixing Findings Is the New Bottleneck #

The adoption numbers make this hard to dismiss. Google’s New SDLC whitepaper estimates that as of early 2026, 85% of professional developers use AI coding agents regularly, 51% use them daily, and roughly 41% of new code is AI-generated. Addy Osmani, one of the authors, wrote a readable summary if you don’t want to read the whole paper.

Coding agents don’t write one function and wait for review. They write, test, read the failures, rewrite, and verify, often several times per hour. Security scanners can keep up with that loop. The old queue of triage, ticketing, and human remediation can’t. At that speed, an AppSec team has plenty of findings and lacks a fast way to turn them into fixes.

The way to close that gap is to return security feedback while the agent still holds the task in its context, so it can repair the problem in the same session. I’d reserve tickets for 2 cases: the in-session loop failed, or new findings surface in artifacts that are already deployed.

Remediation also changes shape at fleet scale. Instead of hunting down individual findings, the AppSec team designs the fix for a whole vulnerability class, and agents apply it to every affected service. I describe this model in more detail in AppSec in the Age of Agentic Engineering.

The Harness Is the Control Plane #

The whitepaper offers a useful mental model: an agent is a model plus a harness. The harness is everything around the model: instructions and rule files, tools and Model Context Protocol (MCP) servers, guardrails, sandboxes, orchestration, and observability. The authors estimate the split at roughly 10% model and 90% harness. Osmani gives a public example in his summary: on Terminal Bench 2.0, 1 team moved a coding agent from outside the top 30 into the top 5 by changing only the harness and keeping the same model underneath.

The harness is also where an AppSec team has the most control. A stronger model helps, but it won’t fix unsafe access defaults, missing tests, or an insecure tool configuration on its own. So I’d ship security skills, local scanning, and review feedback into the harness, where agents can check and improve their own work before a pull request exists.

Shift Security Down into the Platform #

Shift-left still catches mistakes early, but it doesn’t remove the security decisions that every team and every agent has to make. At agent speed, each local workaround becomes a reusable pattern, and architectural drift compounds across the fleet.

That’s why I argued for shift-down security. Instead of asking whether a team implemented authentication correctly, ask why the team needs to implement authentication at all. A mature platform makes that question unnecessary: it exposes APIs with authentication built in, gives workloads scoped identity, and offers a deployment path that is secure by default.

Hardened base images, service templates, platform-owned delivery pipelines, and workload identity remove whole categories of errors and make the secure path the easy path. In my experience, agents follow it. These constraints move undifferentiated choices into a maintained platform, and teams keep the engineering decisions that make their product different. Shift Down: Why Agentic Engineering Demands Platform-Level Security explains this platform role in more detail.

Give Risk an Operational Budget #

Agentic engineering also needs security decisions that work at machine speed. Blocking every finding doesn’t scale, and neither does ignoring them. I suggested borrowing the error-budget model from site reliability engineering (SRE) and applying it to security exposure.

A risk budget caps how long a high-risk, reachable vulnerability may stay in production. Reachability analysis turns raw findings into business exposure: a known vulnerability (CVE) in dead code doesn’t consume the same budget as the same CVE behind a public API. The budget gives people and agents a clear decision rule: fix what burns the budget, defer what doesn’t.

Security then becomes a shared operating concern with an accountable number attached. Instead of an impossible demand (fix every finding), the team decides on an exposure window and defends it.

The Coding Agent Is an Attack Surface #

The agent itself belongs in the threat model. Each task is an untrusted workload: it executes arbitrary code and reads dependency metadata, issue descriptions, pull-request comments, and documentation. That creates a large internal code-execution surface and exposes the agent to prompt injection and excessive agency.

A warning in a rule file won’t protect against that. Run agent tasks in disposable cages, such as nono OS-level sandboxes or Firecracker microVMs, and issue short-lived, task-scoped credentials through an identity broker. Persistent roles and long-lived API keys don’t belong in an agent context.

What I Asked the Students to Learn #

I closed the session with direct advice: learn software engineering deeply, and learn to think in platforms. Get comfortable with distributed systems, identity and access management (IAM), observability, infrastructure as code, and the economics of risk.

Agentic engineering makes AppSec more structural and more software-heavy. The next generation of AppSec engineers will still understand attacks and secure coding, but their biggest impact will come from building paved roads (maintained, secure defaults that teams use without asking), hardening harnesses, and designing systems where insecure choices are rare.

Shift Down: Why Agentic Engineering Demands Platform-Level Security

Sun, 14 Jun 2026 00:00:00 +0200

An organization with 500 engineering teams rarely has a single way to build, deploy, and operate services. It has a preferred path, a few tolerated exceptions, and a long tail of custom setups. Over time, local optimizations pile up on top of historical accidents. Now give every engineer multiple coding agents that produce code at machine speed. The inconsistency does not grow linearly. It compounds.

This is the core tension of agentic engineering for AppSec: Agents amplify whatever patterns exist. Good patterns scale. Bad patterns scale faster. The response most organizations reach for is shift-left: More scanning, earlier detection, faster feedback loops. That helps. But it treats symptoms. The structural answer is shift-down: Embedding security into the platform layer so that insecure choices become difficult or impossible, rather than merely detectable.

Shift-Left Distributes Responsibility. Shift-Down Removes Decisions. #

Shift-left answered the question: Who should own security? The answer was everyone. Development teams run their own SAST, manage their own dependencies, configure their own infrastructure. The intent was sound. The result, in many organizations, was that hundreds of teams now make thousands of security-relevant decisions independently, with varying expertise and attention.

Shift-down asks a different question: Which security decisions should exist at all? Instead of teaching every team to build a secure CI/CD pipeline, the platform ships one standard pipeline that verifies, tests, scans, signs, and deploys by default. Instead of auditing IAM policies across services, the platform binds short-lived credentials to Kubernetes workloads automatically. Instead of reviewing pod security settings and container hardening across the fleet, a platform-owned WebService resource deploys on a managed base image with secure defaults.

The Kubernetes Security SIG formalized this distinction in their shift-down security paper: Security outcomes improve when platforms absorb complexity that individual teams previously handled alone. The two approaches are complementary. Shift-left catches what slips through. Shift-down reduces what can slip through in the first place.

Agentic Engineering Makes This Urgent #

Human engineers introduce inconsistency slowly. A team picks a non-standard auth library. Another team forks a deployment template. Over months, drift accumulates. Organizations notice, create governance processes, schedule remediation campaigns.

Coding agents reproduce inconsistency at machine speed. Every non-standard pattern in the codebase becomes context for generation. Every local workaround becomes a template. Every exception becomes infinitely scalable. The risk is not that agents produce insecure code in isolation. It is that they rapidly multiply architectural entropy across the fleet.

Shift-left tooling (scanners, gates, review agents) catches individual instances after they appear. That was viable when inconsistency grew at human speed. At agent speed, the detection-and-remediation loop cannot keep up. You cannot scan your way out of a problem that regenerates faster than you fix it. The leverage is upstream: Make the inconsistency impossible to produce.

Platforms as Security Architecture #

Good platforms are opinionated. They encode architectural preferences and reject alternatives. This is not bureaucracy. It is engineering leverage: Every abstraction that removes a choice also removes an opportunity for mistakes.

Base images, Dockerfiles, CI/CD pipelines, pod security contexts: These are platform concerns, not product concerns. When organizations treat them as team responsibilities, they get 500 variations of the same solved problem, each with its own security gaps. The alternative: Product teams declare what they need, and the platform handles how it runs securely.

Custom platform resources (Kubernetes CRDs, internal service APIs) abstract entire categories of security decisions. A team declares a WebService resource. The platform operator provisions a hardened container from a managed base image, injects mTLS sidecars, attaches scoped credentials via workload identity, configures egress policies, and wires observability. No Dockerfile. No pipeline YAML. No security context to misconfigure.
Managed identity services issue short-lived, scoped credentials automatically. Teams do not configure service accounts or rotate secrets. They annotate their workload, and the platform binds identity at deploy time.
Platform-owned build and delivery pipelines compile, test, scan, verify, sign, and deploy artifacts without team-maintained configuration. Security scanning is not opt-in. It is invisible. Teams push code. The platform does the rest.

Each of these shifts security from “a thing teams do” to “a property teams cannot opt out of”. Agents, which follow the path of least resistance by design, naturally produce code that fits within platform constraints rather than working around them.

AppSec Moves from Enforcement to Architecture #

Traditional AppSec reviews decisions made elsewhere. Shift-down AppSec decides which decisions should exist. Instead of asking “did this team implement authentication correctly?”, the question becomes “why are teams implementing authentication themselves?”

This reframes the operating model:

From policy documents to platform primitives. The 50-page security standard becomes a set of platform defaults, service templates, and policy-as-code rules. Coding agents (usually) do not read PDFs. They consume MCPs, CLIs and constraints.
From reviewing PRs to designing abstractions. The highest-leverage work is not catching a broken IAM policy in review. It is designing the identity service so that broken IAM policies cannot be expressed.
From remediation campaigns to platform upgrades. When security lives in the platform, fixing a vulnerability class means upgrading the platform once instead of patching hundreds of services individually. The fleet inherits the fix.

This does not eliminate the need for detection. Edge cases exist. Custom integrations break assumptions. New vulnerability classes appear. But detection becomes the fallback, not the primary mechanism.

The Paradox: Less Freedom, More Productivity #

Engineers often interpret constraints as a lack of trust. The evidence points the other direction.

Modern cloud engineers have far less infrastructure freedom than system administrators twenty years ago. They cannot choose their hypervisor, their network stack, or their storage firmware. Yet they are dramatically more productive. Few miss managing physical servers. The same applies to security constraints. Every hour spent on container configuration or pipeline maintenance is an hour not spent on the problem the product engineering team exists to solve. Constraints do not limit productivity. They redirect it toward differentiation.

Where This Leaves AppSec Teams #

Earlier this year, I argued that AppSec must become an engineering discipline: building tooling, shipping remediation at scale, treating risk quantitatively. Shift-down refines the target. The tooling AppSec builds is not primarily scanners and gates. It is platform primitives, secure defaults, and opinionated abstractions that make insecure choices structurally difficult.

This requires a different skill set. AppSec engineers become platform engineers who specialize in security properties. They design APIs and MCPs, build service templates, contribute to infrastructure abstractions, and maintain (or support) the paved roads that the rest of engineering (and their agents) follow.

The organizations that will thrive in an agentic world are not those that allow infinite flexibility. They are those that carefully decide where flexibility should exist and where it should not. Shift-left taught us that everyone owns security. Shift-down teaches us that not everything should remain a choice. The future belongs to teams that understand the difference.

AppSec in the Age of Agentic Engineering

Thu, 14 May 2026 00:00:00 +0200

In agentic engineering, engineers hand tasks to coding agents that write code, run it, and fix their own mistakes in fast loops. Bartosz Ocytko recently mapped where agentic engineering is heading, from a surge of commits on GitHub to bottlenecks in verification, open source, and compute. Most security tooling and processes weren’t built for that volume of change. While reading his piece, I kept coming back to 1 question: what does this shift mean for application security (AppSec)?

Ocytko argues that agentic engineering will reward organizations with strong engineering foundations: those that can verify, coordinate, and safely absorb machine-generated change. I think AppSec is part of that foundation. AppSec teams that already build tooling, run large-scale remediation, and treat risk quantitatively are well placed to make agentic engineering safe at scale. Attackers raise the stakes for strong security engineering, too: Google’s Threat Intelligence Group reports that AI models lower the barrier for adversaries to develop exploits. In May 2026, the group reported the first threat actor it believes used a zero-day exploit developed with AI.

The same agents that create the volume can also help with problems that AppSec teams couldn’t solve at human scale: too many findings, too few security engineers, and feedback that arrived long after the code was written. I see 3 shifts that decide which AppSec teams keep up:

From detection to mitigation: prevent findings inside the agent’s loop and fix the backlog at fleet scale.
From writing policies to building tools: ship security tooling into the context that coding agents work in.
From gatekeeping to partnership: manage security risk together with site reliability engineering (SRE), platform, and cloud engineering teams, the way they already manage reliability.

Findings Pile Up Faster Than Teams Fix Them #

Most mature organizations already have good visibility into known vulnerability classes. Their scanners cover infrastructure, cloud platforms, application code, and continuous integration and delivery (CI/CD) pipelines. AI adds even more findings: HackerOne argues that AI-powered vulnerability discovery has improved by an order of magnitude, while remediation hasn’t kept up.

Backlog data shows how far remediation lags behind. Edgescan, a vulnerability management vendor, analyzed its 2024 scanning and penetration testing results in its Vulnerability Statistics Report 2025. At enterprises with more than 1,000 employees, 45.4% of the vulnerabilities discovered within 12 months were still open. High and critical findings with the highest predicted exploit probability (an Exploit Prediction Scoring System score above 0.7) took 115.7 days on average to fix, slightly longer than the 109.4 days for those least likely to be exploited. Every finding that nobody fixes grows the backlog and extends the exposure window, the time during which an attacker can exploit the vulnerability in production.

Coding agents make this worse. They generate code at machine speed, so new findings appear faster. Lars Janssen calls the growing gap between how fast teams generate code and how fast they can check it verification debt. If remediation still depends on engineers picking up tickets between feature work, the backlog keeps growing. Risk only goes down when teams fix findings faster than scanners discover new ones.

That requires AppSec teams to move from “we found it, you fix it” to “we prevent it, and we fix what slips through”.

Move Security Feedback Into the Agent Loop #

In the traditional loop, a scanner reports an issue in the pipeline, someone files a ticket, and an engineer fixes it when there’s time. In the agentic loop, the scan results go straight back to the coding agent, which rewrites the code in the same session until the checks pass. Many findings never reach a ticket because the agent fixes them before anyone commits the code. GitHub’s Copilot Autofix suggests fixes directly in the pull request, which comes close to this loop. During its 2024 public beta, developers fixed new code scanning alerts in pull requests in a median of 28 minutes, compared with 1.5 hours without Autofix.

Today’s security gates weren’t built for this loop. When a coding agent opens a pull request (PR) in seconds, a security gate that takes minutes becomes the slowest step. Binary gates also break down at this volume: “block on medium severity” blocks everything, and “ignore everything below critical” leaves real risks open. The risk budgets I describe further down give teams a better decision rule.

Some findings will still slip through, and most organizations already carry a large backlog. Fixing them 1 ticket at a time doesn’t scale. In campaign-based remediation, AppSec targets a whole vulnerability class at once, such as an outdated dependency, an infrastructure as code (IaC) misconfiguration, or an insecure pattern repeated across hundreds of services.

Spotify’s fleetshift is a good mental model: it makes fleet-wide code changes by running a Docker image against each repository. Spotify reports that fleetshift created more than 270,000 PRs in 2022 and merged 77% of them automatically, and that it patched 80% of its production backend services within 9 hours of the Log4j disclosure.

With coding agents, the AppSec team designs the campaign, and agents open, test, and verify the remediation PRs across the fleet. GitHub already supports part of this: in security campaigns, teams can assign alerts to the Copilot cloud agent, which opens pull requests with fixes.

Build and Ship Security Tooling #

In this model, AppSec engineers build and ship security tooling and contribute remediation code directly. Their goal is infrastructure that makes coding agents produce secure code by default.

Security Skills and Machine-Readable Policy #

Skills are packaged instructions that coding agents load when a task needs them, and they follow an open specification. Project CodeGuard from the Coalition for Secure AI (CoSAI) publishes general security skills for cryptography, input validation, authentication and authorization, and supply chain security. Organization-specific skills go further and encode internal policies (“use the central auth SDK, not raw JWT handling”), approved libraries, and deployment constraints. If the organization distributes skills centrally, AppSec can publish a skill update when a new vulnerability class appears, and every agent in the organization has it the same day.

The security policy itself needs the same treatment, because a coding agent can’t do much with a 50-page PDF. AppSec teams can turn it into agent instructions, a searchable vector database, or policy-as-code rules that agents check while they work. The agent then verifies compliance mid-task without waiting for a human reviewer, and AppSec’s work moves from reviewing individual changes to maintaining the policies and risk models that agents enforce.

Local Scanners and Review Agents #

Security scanning can’t live only in version control platforms and CI pipelines anymore. Coding agents need static application security testing (SAST), dynamic application security testing (DAST), and reviewers based on large language models (LLMs) on the engineer’s machine, so they can check their own output before they push. AppSec teams package these tools as command-line interfaces (CLIs) or Model Context Protocol (MCP) servers and manage their configuration and policies centrally. MCP gives agents a standard way to call tools. Engineering teams then get scanning that works without setup.

Dedicated review agents combine security skills with local tooling. They check code against organization-specific policies and report issues in a form the coding agent can act on directly. roborev points in this direction: it’s a local daemon that reviews each commit in the background through a git hook and reports every finding with a severity and a file and line location before the code reaches a PR.

A shared review ledger ties these checks together. Every source, whether static analyzer, dynamic scanner, or LLM-based reviewer, writes to the same structured log, typically in the Static Analysis Results Interchange Format (SARIF). The coding agent reads the ledger after each iteration and knows which checks passed, which failed, and what to fix next. LLM-based reviewers can catch context-dependent issues that rule-based scanners miss, but they don’t return the same result on every run, so the ledger needs both.

Sandboxes and Short-Lived Credentials #

Coding agents are most useful when they can run the code they write: they implement a change, run the tests, read the failure, and try again. That makes every agent task an untrusted workload running arbitrary code, often on an engineer’s laptop. For AppSec, this adds up to a large internal remote code execution (RCE) surface, and securing it touches workstation setup as well as engineering practice.

Sandboxing and prompt injection defense go together. A coding agent reads external input such as dependency metadata, issue descriptions, PR comments, and documentation, and each of these can carry a prompt injection that tells the agent to do something else. A sandbox limits the damage when that happens, and the common options differ in isolation strength and cost:

Lightweight virtual machines (micro-VMs) such as Firecracker and Docker Sandboxes give each task a disposable environment with its own kernel.
OS-level sandboxes are lighter. nono applies irrevocable, kernel-enforced filesystem allow-lists through Landlock on Linux and Seatbelt on macOS, and Sandvault runs agents as a separate macOS user inside sandbox-exec. The nono authors point out that OS-level sandboxing doesn’t give the memory isolation of a virtual machine.
Containers share the host kernel, so escaping 1 container puts the attacker on the host.

AppSec picks the isolation boundary that fits each workload’s trust level and, together with platform teams, ships the sandbox setup as the default configuration engineers get out of the box.

Credentials need the same care. Coding agents should never hold persistent identity and access management (IAM) roles or long-lived API keys. An identity broker issues short-lived, task-scoped credentials on demand and revokes them when the task completes. AppSec can build the broker together with platform and IAM teams and hide it behind the agent’s tooling, so agents exchange tokens automatically and never fall back on whatever credential is at hand.

Beyond internal credentials, agents increasingly act on behalf of users in third-party services. That needs delegation and consent infrastructure with narrow, time-limited permissions the user can revoke at any moment. Without it, teams end up storing tokens in agent contexts or hard-coding service accounts, and both fail as soon as an attacker compromises an agent or the agent misreads a prompt.

Threat Modeling and Offensive Testing #

Traditional scanners catch known vulnerabilities listed as Common Vulnerabilities and Exposures (CVEs), common misconfigurations, and obvious injection points. They miss logic flaws such as broken access control across multi-step workflows, business logic bypasses, and race conditions. To catch design-level flaws, AppSec teams have to encode their domain knowledge into agents.

Threat modeling, where a team maps how an attacker could abuse a system’s design, usually happens in periodic workshops. Jack Naglieri built threat models with AI agents and MCP and argues that agents remove the weeks of meetings and documentation review that kept threat modeling a once-a-year exercise. Naglieri’s example comes from detection engineering, but the approach carries over to applications. AppSec teams can build agent setups that regularly review applications and repositories, analyze access control patterns, data flow boundaries, and trust assumptions, and report drift from the organization’s security posture.

Agentic penetration testing (pentesting) complements this, and AppSec can offer it to engineering teams as an internal service. These agents explore the application’s business logic and look for the flaws a human pentester would target: authorization boundaries, multi-step attack paths, and privilege escalation. To build them, AppSec teams turn their offensive expertise into repeatable attack strategies. Public setups today still keep a human in the loop. In AI-assisted web pentesting with Claude Code and Burp MCP, for example, the agent suggests the next test and the pentester decides whether to run it.

Partner With SRE and Platform Teams #

Can a system ever truly be considered reliable if it isn’t fundamentally secure? Or can it be considered secure if it’s unreliable?
Building Secure and Reliable Systems

In SRE, the product owner sets a service level objective (SLO) such as 99.9% availability, and the remaining 0.1% becomes the service’s error budget, which the team can spend on outages and risky releases. AppSec can join that model with a risk budget. The risk budget sets how long a high-risk, reachable vulnerability may stay open in production before it burns error budget, just like downtime does. AppSec provides the framework and the tooling, and the product owner sets the target, just as for the SLO.

A risk budget helps with a problem that agentic engineering makes worse. Coding agents generate change faster than people can triage the findings, and without a quantitative target every finding competes for the same attention. With a risk budget, teams fix what burns the budget and defer what doesn’t. The conversation moves from “fix all the bugs” to “manage the exposure window”, and security becomes an operational concern that AppSec shares with the teams running the service.

Teams can only use a risk budget if they can tell real exposure from noise, and that requires reachability analysis: tracing the call graph from the vulnerable code to the application’s entry points. A CVE in dead code doesn’t burn budget, but the same CVE behind a public API does. At the CI gate, teams then block only changes that introduce reachable risk and stop failing builds on raw finding counts. In production, a monitoring layer tracks how long reachable findings stay open and burns error budget accordingly.

Platform and cloud engineering teams already ship the paved roads that engineering teams build on: base images, service templates, IaC modules, identity primitives, and networking defaults. AppSec teams get the most reach by building security into those golden paths. A hardened base image or a secure-by-default service template then carries security to every service that uses it, including the code that agents write. Platform engineering owns the templates and modules, and AppSec owns the security defaults inside them. I cover this model in more detail in Shift Down.

Where to Start #

None of this has to happen at once. A team that wants to start can work through these steps in order:

Sandbox the coding agents that engineers already run, and replace their long-lived credentials with short-lived, task-scoped ones.
Package the existing scanners as CLIs or MCP servers with central configuration, and make them write SARIF.
Publish an organization-specific security skill that encodes the internal policies that matter most.
Pick 1 vulnerability class from the backlog and fix it across the fleet as a campaign.
Agree on a risk budget for reachable vulnerabilities with 1 service owner and their SRE team.

The sandbox comes first because the exposure exists as soon as an engineer runs an agent with access to their machine.

About Jan Brennenstuhl

Thu, 08 Apr 2021 00:00:00 +0200

Hi. My name is Jan Brennenstuhl, I live and work in Berlin Germany, where I was born and raised. I am a product-minded software engineer, security enthusiast & clean code artist with a huge interest in interdisciplinary software development and engineering leadership. I am a big fan of cycling sports, coffee & hiking.

I currently work in Berlin as principal engineer, focused on application security and making agentic engineering more secure and efficient. I spent years building and operating identity solutions used by millions of customers — balancing UX and security in high-stakes revenue funnels — and have since moved into the broader AppSec space, where I’m most interested in the intersection of security, usability, and automation.

I’ve worked as software engineer and lead on e-commerce funnels, rule engines, cloud strategies, IAM and SSO solutions, REST APIs, system integrations, technology research, legacy migrations, decommissioning projects and modularizing monolithic systems — various things, mostly in e-commerce and security. I practiced software archaeology more than I set up greenfield web services.

I am an internet standards enthusiast, who values open source software and open formats over custom builds. For me, quality software products are created best by small teams of product-minded engineers with a narrow, well-defined business scope and a clear vision. I’m especially passionate about leading and influencing engineers as well as creating and operating reliable, secure and maintainable software products.

I hold a M.Sc. in Computer Science from the University of Potsdam, where I completed my thesis on “Certificate Management in the Cloud for Authentication in university Environment”. I’ve also studied Media Informatics at the Beuth University of Applied Sciences in Berlin.

Agentic Engineering · Brennenstuhl on Security

How does authorization work for MCP servers?

Key findings #

Evidence #

What to do #

For engineers #

For product and UX #

How it works #

Related #

How should people grant and revoke an agent's access?

Key findings #

Evidence #

What to do #

For engineers #

For product and UX #

How it works #

Related #

How does OAuth 2.0 Token Exchange keep provider tokens away from agents?

Key findings #

Evidence #

What to do #

For engineers #

For product and UX #

How it works #

Step through the exchange

Related #

Should an agent use a robot account or delegated access?

Key findings #

Evidence #

What to do #

For engineers #

For product and UX #

How it works #

Related #

What I Learned Building an Identity Broker With Coding Agents

Why We Started With Agent Identity #

We Used Spec Kit From the First Day #

Early Models Wrote Tests That Tested Nothing #

I Wrote Skills for the Libraries the Models Didn’t Know #

Why I Switched Harnesses 6 Times #

Review Takes More Agents Than Writing #

What We Haven’t Solved Yet #

Economies of Scale for MCP and Agents

Materials #

Reading companion #

Agentic Identity Broker

Explore the project #

AppSec in the Age of Agentic Engineering

Materials #

Reading companion #

Guest Lecture at HTW Berlin: AppSec in the Age of Agentic Engineering

Fixing Findings Is the New Bottleneck #

The Harness Is the Control Plane #

Shift Security Down into the Platform #

Give Risk an Operational Budget #

The Coding Agent Is an Attack Surface #

What I Asked the Students to Learn #

Shift Down: Why Agentic Engineering Demands Platform-Level Security

Shift-Left Distributes Responsibility. Shift-Down Removes Decisions. #

Agentic Engineering Makes This Urgent #

Platforms as Security Architecture #

AppSec Moves from Enforcement to Architecture #

The Paradox: Less Freedom, More Productivity #

Where This Leaves AppSec Teams #

AppSec in the Age of Agentic Engineering

Findings Pile Up Faster Than Teams Fix Them #

Move Security Feedback Into the Agent Loop #

Build and Ship Security Tooling #

Security Skills and Machine-Readable Policy #

Local Scanners and Review Agents #

Sandboxes and Short-Lived Credentials #

Threat Modeling and Offensive Testing #

Partner With SRE and Platform Teams #

Where to Start #

About Jan Brennenstuhl