“Analysis is running in parallel (4 agents)…”

That line from an AI coding agent made me stop scrolling. Four agents, working simultaneously. Impressive.

Then, a few lines later, the same agent quietly admitted the catch:

“The four analysis agents are already dispatched with fixed prompts, so I can’t inject that into them mid-run.”

Parallel? Yes. Coordinated? Not even close.

Think about how a real engineering team works. A human notices new information. A human interrupts. A human reprioritizes. A human shares fresh context on the fly. Today’s coding agents mostly can’t. Once work starts, the plan is frozen. It feels less like a collaborative engineering team and more like submitting four batch jobs and waiting for them to finish.

So I went looking for evidence that this is a systemic limitation, not a one-off quirk.

Turns out, Anthropic’s own engineering team has said the quiet part out loud.

Exhibit A: Anthropic’s multi-agent research system

In their write-up on building a multi-agent research system, they describe running subagents synchronously: the lead agent waits for each batch to finish before moving on. By their own account, the lead agent can’t steer subagents mid-run, subagents can’t coordinate with each other, and the whole system can stall waiting on a single slow worker.

Their admission is refreshingly direct: today’s LLM agents “are not yet great at coordinating and delegating to other agents in real time.”

Exhibit B: 16 Claudes vs. the Linux kernel

In February 2026, an Anthropic researcher put 16 Claude agents on a shared codebase to build a C compiler from scratch.

When the work was naturally parallel - hundreds of independent failing tests - 16 agents flew.

But the moment they hit one big shared task, compiling the Linux kernel, it fell apart. Every agent hit the same bug, fixed it, and overwrote each other’s changes. Sixteen agents didn’t help, because all sixteen were stuck on the same problem.

And the coordination mechanism? A bare-bones git-based file-locking scheme. No orchestrator. No live communication between agents.

That’s not a coordination strategy. That’s a mutex with extra steps.

The real leap isn’t more agents

Here’s my thesis: the next big jump in agentic software engineering won’t come from adding agents. It will come from making agents:

• Interruptible - able to absorb new information mid-run
• Context-synchronized - continuously, not at batch boundaries
• Renegotiable - able to re-plan and re-divide work when the situation changes
• Mutually aware - knowing what every other agent is discovering, in real time

The industry is already leaning this way. Anthropic ships a production research system on an orchestrator-worker pattern and is openly exploring the harder version: asynchronous execution, where agents work concurrently and spawn subagents on the fly. They’re candid that this unlocks parallelism but introduces thorny problems around result coordination, state consistency, and error propagation. Other labs are pushing on subagents and parallel execution too.

But dynamic coordination - running agents that update each other’s plans without restarting - is still very much an open problem.

Sound familiar? It should. This is the distributed-systems problem of the AI agent era. The bottleneck is shifting from raw model quality to coordination, ownership, synchronization, and orchestration.

The strongest evidence: there’s no free pattern

In April 2026, Anthropic published a breakdown of five multi-agent coordination patterns. What stands out is that every single one trades one failure mode for another - exactly the “pick your poison” reality anyone who has built distributed systems will recognize:

1. Generator-verifier. One agent produces, another checks against explicit criteria. Solves quality control - but the verifier is only as good as its rubric. A vague “is this good?” check rubber-stamps everything, and the loop can oscillate forever without converging.
2. Orchestrator-subagent. A lead agent plans, delegates, and synthesizes - this is how Claude Code works. Solves clean task decomposition - but the orchestrator becomes an information bottleneck. When one subagent discovers something another needs, it travels back through the lead, and details get summarized away.
3. Agent teams. Persistent workers claim tasks from a shared queue and run autonomously for long stretches. Solves parallel, long-running work - but teammates can’t easily share intermediate findings and can collide on shared files. Exactly the Linux-kernel failure above.
4. Message bus. Agents publish and subscribe to events, so you can add agents without rewiring. Solves scaling an evolving ecosystem - but event flows are hard to trace, and a misrouted event fails silently: handling nothing while never crashing.
5. Shared state. Agents read and write a common store with no central coordinator. Solves real-time collaboration and removes the single point of failure - but agents can duplicate work or fall into reactive loops, burning tokens on work that never converges.

Anthropic’s own advice: start with the simplest pattern that could work, watch where it breaks, and evolve. In production, teams usually end up combining patterns - an orchestrator for the workflow, shared state for the collaboration-heavy parts.

That’s not a solved problem. That’s engineering around trade-offs.

Which is exactly why I keep coming back to the distributed-systems analogy: we’re not chasing the one right pattern, we’re learning to compose imperfect ones. CAP theorem energy, but for agents.

Over to you

Two genuine questions I’d love a second opinion on:

1. Have you come across research or products tackling live coordination between long-running coding agents - not just parallel execution?
2. If you’ve built multi-agent systems in production, which pattern (or combination) did you land on, and where did it break first?

If you’ve got war stories or links on this, reach out.

When your agent books a flight, files a ticket, queries a database, or calls another service on your behalf, it usually authenticates by borrowing a secret that belongs to you - an API key, an OAuth token, a session cookie. It has no identity of its own. To the service on the other end, there is no “the agent.” There is only you, or the application that wrapped you, holding a key that could just as easily have been copied by anyone.

For a chatbot that answers questions, that’s fine. For an autonomous system that plans, chains together services it has never seen before, spends money, and keeps working while you’re asleep, it’s a genuine problem - one that touches security, accountability, and governance all at once.

A new Internet-Draft called AAuth (Agent Authorization) is one of the more serious attempts to fix it. It’s worth understanding not because it’s guaranteed to become the standard - it isn’t, and I’ll be honest about that throughout - but because it names the problem unusually clearly and proposes a concrete, buildable answer.

This post walks through what AAuth is, the specific cracks it’s trying to fill, and how it works, in language aimed at anyone technical-adjacent. Where I’m summarizing the specification I’ll say so; where I’m interpreting or editorializing, I’ll flag it.

A note on sources and freshness. Everything here is grounded in the AAuth Protocol Internet-Draft (draft-hardt-oauth-aauth-protocol) and the author’s own explainer at aauth.dev. I’m writing against draft revision -09, which I read directly, cross-checked against the public IETF datatracker in mid-2026. This is a fast-moving individual draft - details, endpoint names, and even the exact revision number will have changed by the time you read this. Treat specifics as “true as of -09, verify against the live spec,” not gospel.

TL;DR

• The problem: AI agents have no independent identity. They authenticate by holding copyable secrets (API keys, bearer tokens) that belong to a user or app. Anything copyable eventually leaks, and a stolen secret works for whoever holds it.
• The core idea: Give every agent its own cryptographic identity - an identifier like aauth:local@domain bound to a private signing key. The agent signs every request instead of carrying a password. Steal the token, and it’s useless without the key.
• Who’s behind it: Dick Hardt, the editor of OAuth 2.0 itself, who concluded OAuth doesn’t fit AI agents after building authorization for an MCP server.
• The shape: Four “access modes” that climb from replace your API keys up to full cross-company policy federation. You adopt only as far as you need. Plus a genuinely new idea - missions - that lets you govern an agent by its declared intent, in plain language.
• The honest status: An early, rapidly iterating individual IETF draft - not an adopted standard, and not the only proposal in this space. Whether it wins is unknown. The problems it names are real regardless.

Part 1 - The quiet problem: agents borrow your keys

Software used to be written. A developer decided, at build time, exactly which services an application would call and what permissions it needed. You registered the app once at each service’s developer portal, got a client ID and a secret, wired them in, and shipped. The list of integrations was fixed and known in advance.

AI agents don’t work like that. They discover what they need at runtime. They assemble a chain of tool calls one step at a time, deciding the next move as a task unfolds. They run long tasks that cross between different companies and clouds. And they routinely need a decision - a “yes, go ahead” - in the middle of a task, long after the human who started them has walked away.

The authentication machinery underneath was built for the old world. When you drop an autonomous agent onto it, the seams start to show. Let’s look at exactly where.

Part 2 - Why the tools we already have don’t fit

AAuth’s framing of the problem is sharp enough that it’s worth going through the specific cracks. None of these are exotic - they’re all things any engineer who has wired up an agent has bumped into.

1. Identities don’t travel between services. In OAuth and OpenID Connect - the standards behind almost every “Sign in with…” button - a client has no identity of its own. A client ID issued by Google is meaningless at GitHub. The client only “exists” in the context of each server it has pre-registered with. That made sense when a human developer could visit each portal once. It falls apart when an agent needs to touch a dozen services it has never registered with.

2. Copied secrets leak. Always. API keys are the purest version of the old model: a shared secret that a service issues and you copy into wherever your code runs, then present as a bearer credential. The draft puts the core truth bluntly - any secret that has to be copied to where a workload runs will, eventually, get copied somewhere it shouldn’t. And a bearer credential works for whoever holds it. Steal it, and you are the client.

3. Consent arrives late - and “waiting” isn’t a supported state. An agent frequently needs a human’s approval partway through a task (“this purchase is over your limit - okay?”). But approvals happen on human timelines, which might be minutes or hours. Today’s protocols tend to treat “pending, waiting for a human” as an error rather than a normal, first-class part of the flow.

4. Scopes describe access, not intent. A permission - a “scope” like mail.read - is standing access. It looks exactly the same whether the agent is summarizing your inbox or quietly scraping it. For an autonomous system making its own choices, why it’s acting right now matters as much as what it’s allowed to touch, and scopes simply can’t express that.

5. Tool chains assemble live. The sequence of calls an agent makes isn’t written into its code. It picks the next tool as it goes, and the chain shifts with every task. Authorization models that assume a fixed, declared set of integrations have nothing to grab onto.

6. Work crosses trust boundaries. Enterprise “workload identity” systems like SPIFFE and WIMSE are genuinely good - a workload can prove who it is without shared secrets. But they operate within a single organization’s trust domain. They don’t help an agent that needs to reach across organizational borders, or a developer’s tool running outside any enterprise platform at all.

Put those six together and a pattern emerges: the thing that’s missing is an identity for the client itself - one that it carries with it, that any party can verify, and that survives crossing between services and companies.

Part 3 - The one idea worth remembering

If you take away a single sentence from this whole post, make it this one:

Give every agent its own cryptographic identity, and have it sign every request instead of carrying a password.

That’s AAuth’s foundation. Concretely:

• Each agent gets an identifier of the form aauth:local@domain - think of it like an email address for the agent, where domain belongs to whoever issued it.
• That identifier is bound to a private signing key that lives with the agent and never leaves it.
• The agent’s public key is published at a well-known URL, so any party can look it up and verify a signature - no pre-registration, no shared secret, no dependency on a particular central server.
• On every request, the agent produces a cryptographic signature over that request. The receiving service checks it against the published public key.

The security payoff is the part worth sitting with. A bearer token (an API key, a cookie) is dangerous because possession equals authority - whoever holds the bytes wins. A signed request is different: even if an attacker intercepts the token, it’s worthless without the private key, which never travelled. Cryptographers call this proof-of-possession. In plain terms: the agent doesn’t just claim to be who it says - it proves it, on every single call.

That’s it. Everything else in AAuth - modes, tokens, missions, federation - is built incrementally on top of that one move.

Part 4 - Who’s proposing this, and why that matters

It would be easy to dismiss “yet another auth protocol.” What makes AAuth worth a second look is who wrote it and why.

AAuth comes from Dick Hardt - and here’s the detail that should raise an eyebrow: Hardt was the editor of OAuth 2.0 itself (the person listed as “Ed.” on RFC 6749, the framework the modern web runs its logins on). He’s also a co-author of the in-progress OAuth 2.1.

By his own account on aauth.dev, the origin story is this: after implementing authorization for an MCP server - the “Model Context Protocol” used to connect AI models to tools - he concluded that OAuth simply isn’t a good fit for that world, and started working with others in the identity community who’d hit the same walls. AAuth is what came out of it.

His one-line thesis is the cleanest summary of the whole effort:

“The web gave servers identity. It’s time clients got the same.”

• Dick Hardt, aauth.dev

You don’t have to agree that AAuth is the answer to take the diagnosis seriously. When the person who edited OAuth 2.0 says OAuth 2.0 isn’t enough for agents, that’s a signal worth weighing - though, in fairness, it’s also exactly the kind of claim an author is motivated to make about their own new proposal. Judge the design on its merits.

Part 5 - The four access modes: a ladder, not a leap

The single smartest design decision in AAuth, in my reading, is that it’s incremental. You don’t have to swallow the whole thing. It defines four “resource access modes” that climb from trivially simple to fully featured, and - crucially - every party can adopt independently, with no coordinated migration. A service that doesn’t understand AAuth just ignores the signatures and keeps working.

Here are the four rungs, in plain language:

Rung 1 - Identity-based access. Replaces API keys. The agent signs its request; the service verifies who it is and applies its own access rules. There’s no authorization dance and no extra tokens - just cryptographic identity in place of a shared secret. This is the “drop-in for API keys” mode, and it involves only the agent and the resource.

Rung 2 - Resource-managed access (two-party). Replaces OAuth. The service keeps whatever authorization it already has - consent screens, existing OAuth tokens, sessions - and simply wraps it. It hands back its own token, but bound to the agent’s signature so it can’t be stolen and replayed as a standalone bearer token. Still just the agent and the resource; still no new central party.

Rung 3 - Person-server access (three-party). Now a new character enters: a person server that speaks for you. It’s a server you choose (not one imposed by anyone else) that can prove who you are to a resource, handle consent on your behalf, and keep an audit trail - and it works across many services without each of them having to set you up in advance.

Rung 4 - Federated access (four-party). The most capable mode. The resource has its own policy engine (an “access server”), and your person server negotiates with it directly. This is what enables agents to cross organizational borders under real policy control.

The important property: each step is optional and additive. A service that adopts only Rung 1 still gets real value (leak-proof identity instead of API keys). It never has to climb higher than its needs require. That’s a very different adoption story from “rip everything out and migrate.”

Part 6 - The cast of characters (and the three tokens)

To read anything else about AAuth, it helps to know the players. The specification is careful about roles, and once you have them, the flows make sense.

• Person - a human or an organization: the legal party on whose behalf the agent acts, and who is ultimately accountable for what it does.
• Agent - the HTTP client acting for the person, identified by that aauth:local@domain URI.
• Agent Provider (AP) - the server that vouches for the agent’s identity by issuing it an “agent token.” Think of it as the passport office for agents.
• Resource - the service being accessed (an API, a data store). It may enforce its own policy or delegate that to an access server.
• Person Server (PS) - the server that represents you to everything else: manages missions, handles consent, asserts your identity, brokers authorization. You pick it, and you can move to a different one whenever you like.
• Access Server (AS) - a policy engine that evaluates requests and issues access on a resource’s behalf, in the four-party mode.

And three kinds of token, each a signed JWT tied to whoever issued it:

• Agent token - establishes who the agent is (issued by the agent provider).
• Resource token - describes what access is being requested (issued by the resource).
• Auth token - actually grants access, carrying identity claims and/or authorized scopes (issued by a person server or access server).

You don’t need to memorize this. The mental model is enough: an agent has a verifiable identity, it asks a resource what it needs, and a party you trust turns that into a grant - all signed, all bound to keys, no copyable bearer secrets in the mix.

One privacy detail worth calling out, because it’s a nice touch: the person server can hand each resource a different, pairwise identifier for the same user. So two services you use can’t quietly compare notes and realize you’re the same person. Identity without automatic cross-site correlation.

Part 7 - Missions: the genuinely new idea

If Rungs 1-4 are AAuth catching authentication up to the agent era, missions are where it tries to get ahead of it. This is the part I find most interesting, and it’s the piece that most directly answers “scopes describe access, not intent.”

A mission is a short, human-readable description - written in plain language - of what the agent is actually trying to accomplish. The agent proposes it; you (through your person server) review, maybe ask a clarifying question or two, and approve it once. From that point on, the approved mission is fixed - it can’t be quietly edited out from under you, because it’s pinned by a cryptographic hash of its contents.

Here’s why that’s powerful. Instead of every request being judged only against a static permission list, each action can be weighed against the mission:

“Does this next step actually fit the mission I agreed to?”

That question can be answered by a human or by an AI acting as the decision-maker - and it can catch things a fixed rulebook never could. mail.read can’t tell “summarize my inbox” apart from “scrape my inbox,” but a mission can: one is on-mission, the other isn’t.

Around missions, the person server offers a few concrete governance tools:

• A mission log - an ordered record of every interaction in the mission, so the whole thing can be reconstructed later for audit or investigation.
• A permission step for sensitive actions the agent wants to take that aren’t governed by any remote resource (tool calls, file writes, sending a message).
• An interaction channel to reach you mid-task - relay a question, forward a payment approval, or propose that the mission is complete.
• A clarification chat - during consent, you can ask the agent questions, and it can explain itself or adjust its request before you approve.

My editorial read: missions are the most ambitious and least battle-tested part of the design. They’re also the most honest about what agent governance actually requires - because a lot of the decisions we want to make about autonomous agents genuinely can’t be reduced to machine-evaluable rules written in advance. Whether “a plain-language mission plus a hash” is a strong enough container for that is exactly the kind of thing that needs real-world implementation to settle. (It’s telling that “missions” were added as a first-class object partway through the draft’s life, and remain actively debated in the community - a sign this is live design, not settled fact.)

Part 8 - What actually makes it safer (and where it’s honest about limits)

A protocol’s security story is only as good as its willingness to name its own weak points. AAuth’s does reasonably well on that front. The genuine improvements:

• No bearer tokens anywhere. Every credential is bound to a signing key and is useless without it. This is the single biggest change from the status quo.
• Proof-of-possession on every request. A stolen token can’t be replayed by someone who doesn’t hold the key.
• Confused-deputy protection. Resource tokens are bound to a specific resource’s identity, which blocks a class of attacks where one service is tricked into acting for another.
• Layered revocation. Multiple parties - the agent provider, your person server, the access server - can each independently deny renewal or revoke access. Short token lifetimes shrink the window between “revoke” and “expired.”
• Accountability by construction. The spec insists each agent is bound to exactly one accountable person. Every action an agent takes traces back to a single party - which is precisely what enterprise audit and incident response need.

And the limits it’s upfront about - which I appreciate, because a spec that only lists its strengths is a spec to be suspicious of:

• The person server is a high-value target. It sees every authorization an agent makes. Compromise it and you’ve compromised a lot. The design leans on “you chose it and can leave it” plus the option to delegate authentication and policy elsewhere, but centralization risk is real and acknowledged.
• Signatures prove authenticity at request time, not forever. Agent keys are short-lived and rotated, so once a key is retired you can’t re-verify an old signature by re-fetching the public key later. If you need durable, long-term non-repudiation (for compliance, say), you have to capture the evidence at the moment of verification - the draft spells out how, and is clear this trades some privacy for that durability.
• All input is untrusted. Justifications, mission descriptions, clarification replies - all of it can come from an adversary and must be sanitized before it’s shown to a human. (This matters especially because so much of it is free-form Markdown that gets rendered.)

That last cluster is the mark of a design that’s been thought about seriously rather than sketched.

Part 9 - How it fits with OAuth (it doesn’t kill it)

A fair worry when a new protocol appears is: does adopting it mean tearing out what I have? For AAuth, the answer is no, by design.

• It’s built to coexist with OAuth 2.0 and OpenID Connect, not replace them.
• It reuses their vocabulary - the same scope values and identity claims - specifically to lower the cost of adoption for services that already speak OIDC.
• It follows familiar patterns: publishing metadata at well-known URLs and signing keys via JWKS endpoints, the same way OAuth and OIDC discovery already work.
• The whole thing rests on existing web standards, chiefly HTTP Message Signatures (RFC 9421) for the signing.

And the adoption model is deliberately un-dramatic: a service that recognizes AAuth signatures verifies them; one that doesn’t ignores them and keeps working. There’s no flag-day, no central coordinator, no requirement that everyone move at once. Each party climbs the ladder on its own schedule.

Part 10 - Where this actually stands (the honest part)

This is the section I’d want a reader to remember if they remember only one, because the temptation with a clean new protocol is to assume it’s further along than it is.

It is an individual IETF Internet-Draft - not an adopted standard. Anyone can publish an Internet-Draft; doing so confers no official standing. As of the revision I read, it targets the security area but has no working group formally behind it yet. There is real momentum around it - a family of related drafts (bootstrapping guidance, an events spec, an exploratory “rich resource requests” vocabulary), open-source SDKs in a few languages, a demo you can run against a live test resource, community Slack channels, and in-person meetups. But momentum is not ratification.

It is not the only proposal in this space. Other efforts are floating extensions to OAuth 2.0 to handle AI-agent authentication and authorization rather than a new protocol. The industry has very much not converged on an approach. Reasonable, expert people disagree about whether agents need a whole new protocol or whether OAuth can be stretched to fit.

Whether AAuth becomes the standard is genuinely unknown - and I’d be suspicious of anyone who tells you they know. New protocols face a brutal chicken-and-egg problem: resources won’t implement it until agents use it, and agents won’t use it until resources implement it. AAuth’s incremental, “ignore-it-if-you-don’t-support-it” design is a smart hedge against exactly that, but plenty of well-designed protocols never reach escape velocity.

None of that makes it a waste of time to understand. The problems AAuth names - no client identity, leaky secrets, mid-task consent, intent versus access, cross-domain trust - are real, and they’re going to have to be solved by something, whether that something is AAuth, an OAuth extension, or an idea not yet written down. Understanding the clearest articulation of the problem is useful no matter which answer wins.

Part 11 - How to look closer

If this made you curious, a few concrete next steps (all first-party sources):

• Read the draft. The IETF datatracker page for the AAuth Protocol is the authoritative spec: datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol. It’s readable, with wire-level examples of every flow.
• Start with the explainer. aauth.dev lays out the “what changed” case and has an interactive protocol explorer.
• Try it hands-on. There’s a walkthrough that bootstraps a real agent identity and makes signed calls to a test resource, which you can drive from a CLI agent. It’s the fastest way to feel the difference between a signed request and a bearer token.
• Watch the design argue with itself. The GitHub repo (github.com/dickhardt/AAuth) has the open issues and discussions - the best place to see which parts (missions especially) are still contested.

I’d genuinely encourage forming your own view rather than taking mine. I’ve tried to represent the design fairly and flag where I’m interpreting versus reporting, but I have opinions (I think the incremental-adoption story is the strongest part and the missions layer is the most interesting-but-unproven), and you should discount them accordingly.

The question underneath it all

Strip away the tokens and the RFC numbers and AAuth is really about a single question we’re going to have to answer as AI agents move from demos into real infrastructure:

Do we keep letting agents borrow our passwords - or do we give them identities of their own that we can actually govern?

AAuth is one serious, well-argued proposal for the second path, from someone with the credibility to make it. It might win. It might not. But the question isn’t going away, and it’s a good one to have thought about before the systems you depend on quietly answer it for you.

Written from a close reading of the AAuth Protocol Internet-Draft (revision -09) and the author’s explainer at aauth.dev, cross-checked against the public IETF datatracker in mid-2026. Because this is a fast-moving draft, verify any specific detail against the live specification before relying on it. Corrections welcome.

It took me longer than I want to admit to find the actual rule, because most explanations of Go modules assume one module per repository and stop there. My repo had four. So I built a small, real monorepo to pin the rule down for good: go-multimodule-poc, four independently versioned Go modules in one Git repository, plus go-multimodule-poc-consumer, a downstream project that pulls specific versions from it. Every command below actually ran against that repo. Keep reading and you’ll be able to reproduce the exact failure - and the fix - yourself.

TL;DR: nested-module tags need their full directory path or go get can’t see them, a nested go.mod is a hard boundary ./... never crosses, Minimal Version Selection picks the ceiling of everyone’s declared floor rather than the newest tag anywhere, and go.work/replace are both local-only - no consumer ever sees either one. The rest of this post is where those rules come from and what breaks when you get them wrong.

Why put four modules in one repository

A Go module is a unit of versioning: one go.mod, one semver history, one set of Git tags. A repository is just a place to keep files. Go does not require these to be the same thing, and for a set of small, tightly related components that release independently but get worked on together, keeping them in one repo has real advantages: one CI pipeline, one issue tracker, atomic commits across boundaries during a refactor, and no cross-repo dependency dance while you’re mid-change.

The cost is that Git tags, which are global to a repository, now have to disambiguate which module a v1.1.0 refers to. That disambiguation is the entire mechanism this post is about.

My test repo has four modules under entities/:

• github.com/abhi4u1947/go-multimodule-poc/entities/shared-lib - a small logger, config store, and string helpers, imported by everything else.
• github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc - a stand-in service with a cmd/, an internal/ package, and its own dependency on shared-lib.
• github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/estargz and .../shopping-svc/ipfs - two more modules, each with their own go.mod, physically living inside shopping-svc’s own directory tree.

That last detail is not an accident. It’s the part that breaks most people’s mental model, and it’s where I’ll start.

What’s actually in this repo

Here’s the real layout, from the repo root:

go-multimodule-poc/
├── go.work
├── entities/
│   ├── shared-lib/
│   │   ├── go.mod
│   │   └── logger/  config/  utils/
│   └── shopping-svc/
│       ├── go.mod
│       ├── cmd/shopping/  api/  internal/  pkg/  version/
│       ├── estargz/
│       │   └── go.mod          # independent module
│       └── ipfs/
│           └── go.mod          # independent module
└── tools/
    └── goproxy-gen/
        └── go.mod              # a fifth module, deliberately unpublished

Notice what’s missing: there is no go.mod at the repository root. go-multimodule-poc is not itself a Go module. It’s a container - a directory that happens to hold five independent module graphs (four published, one internal tool). This is the thing people mean when they say “Go monorepo,” and it surprises people coming from ecosystems where the repo root usually is the package.

Each go.mod’s module line, read straight from the source:

estargz and ipfs sit inside shopping-svc’s directory but are not part of the shopping-svc module. That’s not a comment I’m adding for effect - it’s mechanically true, and the next section shows exactly where Go draws that line.

Where does shopping-svc end and estargz begin: module boundaries in practice

Run go build ./... from inside entities/shopping-svc and watch what gets included. From that repo, with the workspace file disabled so it can’t paper over module boundaries:

$ cd entities/shopping-svc
$ GOWORK=off go list ./...
github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/api
github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/cmd/shopping
github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/internal
github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/pkg
github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/version

estargz/ and ipfs/ are physically sitting right there in the same directory tree. They do not appear. Not filtered out, not excluded by a config flag - Go’s ./... expansion walks down from the current module’s root and stops the instant it finds another go.mod. The directory becomes a hard wall. shopping-svc has to depend on estargz the same way an outside consumer would: a require line and a real version, never a relative import.

I wrote this up in more detail in the repo’s own module-discovery notes, including the walk in both directions - up to find “what module am I in,” down to expand ./.... The short version, as a picture:

This is also why go.work exists in this repo at all. Four independent modules means a normal go build in one of them can’t see uncommitted edits in the others without a real published version - exactly like an outside consumer. go.work tells the toolchain “use these local directories for these module paths” during development, without touching any go.mod. It’s a pure local override. The moment you leave this repository, go.work doesn’t exist as far as anyone else is concerned - which is exactly why the consumer repo needs a different tool for the same job, covered later.

The tag-naming rule

Here’s the rule, stated once, precisely: for a module whose go.mod lives in a subdirectory of the repository root, the release tag must be the module’s directory path relative to the repo root, followed by /vMAJOR.MINOR.PATCH. A module whose go.mod sits at the repository root uses a bare vX.Y.Z with no prefix - but none of this repo’s four modules qualify, since none of them live at the root.

Applied to this repo, using git ls-remote --tags against the live repository:

(There’s also a stray entities/shared-lib/v0.1.0 tag on the real remote, left over from a bug in the release automation that I’ll come back to. It’s the kind of thing this rule makes easy to create by accident and easy to spot once you know what you’re looking at.)

That entities/ prefix is the whole answer to the failure I opened with. A tag named shopping-svc/v1.0.0 - no entities/ - looks completely reasonable if you don’t know the module’s real path on disk. It is also not a tag that resolves to anything, because the actual directory is entities/shopping-svc. I proved this the hard way while building this repo: I created a tag at exactly that wrong, shorter prefix, pointing at real content that has a correct, matching tag elsewhere, and asked go get for it:

$ go get github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/estargz@v0.18.4
go: github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/estargz@v0.18.4:
    invalid version: unknown revision entities/shopping-svc/estargz/v0.18.4

That transcript is genuine, captured while constructing this repo (full context in docs/experiments.md, experiment 4) - I did not leave the wrong-prefix tag on the public repo afterward, so a fresh git ls-remote today will not show it. I’m calling that out explicitly because I’d rather tell you a demonstration tag no longer exists than let you go looking for it and think the mechanism stopped working. go matches tags by exact ref name. There’s no fuzzy fallback, no “did you mean,” nothing that scans for a tag containing the right version number at the wrong location. If the ref isn’t there byte-for-byte, it doesn’t exist, even if a tag with the same suffix does exist three directories over.

The resolution direction works the same way in reverse. Given .../entities/shopping-svc/estargz@v0.18.2, here’s what go actually does, and I’ve annotated each step against the real repo:

requested:  github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/estargz @ v0.18.2

1. Try successively shorter prefixes of the module path as candidate
   repository roots, longest first:
     .../entities/shopping-svc/estargz   -- not a repo root
     .../entities/shopping-svc           -- not a repo root
     .../entities                        -- not a repo root
     github.com/abhi4u1947/go-multimodule-poc  -- yes, this is the repo

2. Subtract the repo root from the module path to get the subdirectory:
     entities/shopping-svc/estargz

3. Append the requested version to get the expected tag:
     entities/shopping-svc/estargz/v0.18.2

4. Look up that exact ref. It exists, pointing at commit 204b1d6.
   Read entities/shopping-svc/estargz/go.mod from that commit's tree.

I confirmed step 4 independently of go with git show entities/shopping-svc/estargz/v0.18.2 --stat - the tag really does point at a commit containing exactly that subdirectory’s files. Full transcript in experiment 9.

Releasing one module without touching the others

Independent versioning is the entire point of splitting a repo into modules this way: a change to estargz should cut an estargz release, not a shopping-svc release, even though estargz lives inside shopping-svc’s directory. I automated this with .github/workflows/release.yml, and the interesting part is not the tagging - it’s correctly figuring out which module changed.

The workflow diffs the push against its parent commit, then attributes changed files to a module by checking directory prefixes longest first: shopping-svc/estargz and shopping-svc/ipfs before the bare shopping-svc. Skip that ordering and a change under entities/shopping-svc/estargz/ would get misattributed to the parent shopping-svc module, since entities/shopping-svc/estargz/foo.go also starts with entities/shopping-svc/. Once a module’s identified, the job builds and vets it standalone (GOWORK=off, so the local workspace file can’t hide a real problem), computes the next patch version from the last matching tag, tags it, and cuts a GitHub Release.

That “last matching tag” lookup taught me a sharper lesson than I expected. My first version used grep -Ev -- '-' to filter out pre-release-looking tags. It silently excluded every single tag for shared-lib, because the string shared-lib itself contains a hyphen. The fix was an exact-match regex - ^entities/shared-lib/v[0-9]+\.[0-9]+\.[0-9]+$ - not a “does it look weird” heuristic. That bug shipped one bad tag, entities/shared-lib/v0.1.0, before I caught it; it’s the stray tag mentioned in the table above, and it’s a small, honest illustration of how easy it is to get tag-matching subtly wrong even when you know the rule.

Three requirers, one winner

Before you scroll past this paragraph: three different modules in this repo each state a different minimum version of shared-lib. When a consumer pulls in all three, Go has to pick exactly one version of shared-lib for the build. Which one does it pick - the newest available anywhere, the oldest anyone asked for, or something else? Decide before you read the table.

The rule is called Minimal Version Selection, and despite the name it does not pick the lowest number on the list. It picks, for each dependency, the maximum of every minimum anyone in the build graph declared - the lowest version that is still high enough to satisfy every stated requirement at once. Here that’s max(v1.1.0, v1.0.0, v1.0.0) = v1.1.0. Not the newest tag that exists anywhere (shared-lib has since gone on to v1.1.1), not the oldest - the ceiling of everyone’s floor.

I reproduced this from a clean scratch module against the real, live repository, requesting each dependency in the exact order a first-time consumer would:

$ go get github.com/abhi4u1947/go-multimodule-poc/entities/shared-lib@v1.0.0
go: added .../entities/shared-lib v1.0.0

$ go get github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc@v1.1.0
go: downloading .../entities/shared-lib v1.1.0
go: upgraded .../entities/shared-lib v1.0.0 => v1.1.0
go: added .../entities/shopping-svc v1.1.0

$ go get github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/estargz@v0.18.2
go: added .../entities/shopping-svc/estargz v0.18.2

$ go get github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/ipfs@v0.18.2
go: added .../entities/shopping-svc/ipfs v0.18.2

The moment shopping-svc enters the graph, shared-lib jumps from v1.0.0 to v1.1.0 on its own - nobody ran a second command telling it to. Adding estargz and ipfs afterward, whose own stated floor is only v1.0.0, doesn’t pull it back down. MVS only ever moves a selected version up, never down, which is what makes builds reproducible from go.mod and go.sum alone: there’s no resolver out there that might hand you a different answer next Tuesday.

Two things worth being precise about, because I got tripped up by both while building this.

First: go mod graph prints the raw edges exactly as each go.mod declares them. estargz and ipfs still show shared-lib@v1.0.0 there, forever - that’s genuinely what their go.mod says. go list -m all prints the outcome of MVS instead: one line per module, the version actually selected. Read the wrong one and you’ll think there’s a bug where there isn’t.

Second: today, shared-lib’s real latest tag is v1.1.1, one patch ahead of what shopping-svc requires. Go treats the first sight of an unresolved import as “give me whatever’s newest,” so a totally fresh go mod tidy on a brand-new module lands on v1.1.1 directly, without walking through v1.1.0 first. Both routes are MVS-consistent - v1.1.1 still satisfies everyone’s stated floor - they just get there for different reasons. The consumer repo’s own committed go.mod sits at v1.1.1 for exactly this reason, even though its README still says v1.1.0 in a few places. The code moved on; the prose didn’t. Check git log, not the README.

Pseudo-versions are what you get when you ask for a commit that has no tag at all. I asked for the current, real, untagged tip of main in this repo:

$ go get github.com/abhi4u1947/go-multimodule-poc/entities/shared-lib@6f79cb92532cd48c86eb93c0974ad59d5bb55934
go: downloading .../entities/shared-lib v1.1.2-0.20260703130951-6f79cb92532c

Read the pieces: v1.1.2 is one patch past v1.1.1, the highest real tag reachable from that commit. A pseudo-version has to sort strictly after the release it follows, so Go bumps the patch component to make that true. 20260703130951 is the commit’s UTC timestamp. 6f79cb92532c is the first twelve hex characters of the real commit SHA. None of it is invented - it’s a deterministic encoding of “this exact commit, one step past the last release.”

One caveat cost me a few confused minutes: you can’t hand go get a branch name with a slash in it as the @version. Go rejects anything containing / in that position with disallowed version string - I confirmed this on both the go1.24.7 toolchain I verified everything else on and a later go1.26.1 build, so it’s not a version-specific quirk. Resolve the branch to a commit SHA first, then query by that.

For local development, this repo uses two different tools for two different situations, and it’s worth being clear that they don’t overlap. Inside go-multimodule-poc itself, go.work lets all four modules build against each other’s on-disk state at once. From outside the repo - which is where the consumer lives - go.work doesn’t apply, so the consumer instead uses a replace directive:

replace github.com/abhi4u1947/go-multimodule-poc/entities/shared-lib => ../go-multimodule-poc/entities/shared-lib

(from go.mod.replace-example in the consumer repo). With that line present, every build resolves shared-lib from the local checkout - unpublished, untagged, whatever’s on disk - and the version string in require becomes cosmetic while the directive is active. Remove the line and resolution snaps straight back to the tagged version in go.sum, with nothing else to change. I verified both states directly: with the replace line in, a locally patched log line showed up in the program’s output immediately; with it removed, the output went back to exactly what the tagged release produces.

Consuming it for real

The consumer repo’s main.go imports all four modules independently, sub-packages included, not just module roots:

import (
	shopping "github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/version"
	estargz  "github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/estargz/version"
	ipfs     "github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/ipfs/version"

	estargzpkg "github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/estargz/pkg"
	ipfspkg    "github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/ipfs/pkg"

	"github.com/abhi4u1947/go-multimodule-poc/entities/shared-lib/logger"
)

Getting a specific version of one of them is a plain go get module@version - no special syntax for “this is a nested module,” because as far as the consumer is concerned it’s just another module path:

$ go get github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/estargz@v0.18.2

go mod tidy afterward reconciles the full require block against what’s actually imported, adding anything missing and dropping anything unused, and writes the resolved content hashes into go.sum.

Four commands read the result back in different, non-overlapping ways, and mixing them up is an easy way to misdiagnose a version problem:

• go list -m all - one line per module, the version MVS actually selected for the build. This is “what will I compile against.”
• go mod graph - every raw requirement edge, exactly as each go.mod declares it. estargz’s edge to shared-lib will show v0.18.2 -> v1.0.0 here forever, regardless of what version actually gets selected. This is “who asked for what.”
• go mod why -m <module> - the shortest import path from the main module to that dependency, or a note that it isn’t needed. Without -m, go mod why <path> asks a narrower question - “is this exact package path imported” - and will tell you a module “does not need” a package that lives at the module’s own root if you only ever import its subpackages, which is exactly this repo’s shape.
• go list -m -json <module> - the same information a proxy would hand back for that module, as structured JSON: path, version, commit time, on-disk cache location, and the go.sum hashes.

The consumer’s README walks all four with real transcripts against this exact dependency set, and I re-ran each of them fresh against the live repository while writing this post; they still match.

Staying current is where the two repos actually talk to each other. The consumer has Dependabot configured for the gomod ecosystem on a daily schedule - ordinary Dependabot behavior, it doesn’t know or care that the upstream is a monorepo. Layered on top, the producer’s release workflow fires a repository_dispatch event (module-released) at the consumer the moment it tags a new version, and the consumer’s auto-update.yml reacts by bumping exactly that module and opening a PR within seconds instead of waiting for the next scheduled check. If the dispatch never arrives - the producer’s CONSUMER_DISPATCH_TOKEN secret isn’t set, say - the same workflow still runs on its own daily cron and on manual dispatch, bumping every tracked module to @latest as a fallback. Dependabot is the safety net; the dispatch is the fast path. Neither one depends on the other working.

Three ways this breaks

Module path mismatch. go.mod’s module line is the only source of truth for a module’s identity - not the tag, not the URL you fetched it from. If a module gets fetched at path P but its own go.mod declares path Q, go refuses before it ever reads a line of code:

module declares its path as: github.com/abhi4u1947/go-multimodule-poc/estargz-wrong-path
        but was required as: github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/estargz

I built this exact scenario while constructing the repo - a copy of estargz with its module line pointed at the wrong path, tagged and fetched as if it were the real thing. The full transcript is in experiment 3. As with the wrong-prefix tag earlier, I didn’t leave that broken tag on the public repo afterward, so it isn’t something you can fetch from GitHub today - the error text above is genuine, captured output, not a guess at what the message would say. The check itself exists for a real reason: without it, a compromised or misconfigured module could quietly answer to a trusted import path it doesn’t actually own.

Wrong-prefix tags. Covered above, worth restating as its own failure mode because it’s the one I actually hit in production: a tag can contain the exact right version string and still resolve to nothing, because go matches refs by exact name, not by scanning for a tag that merely mentions the right number somewhere in the repo.

Module identity survives the tag; the tag doesn’t survive resolution. This repo has a genuinely interesting case of it: two different tags, entities/shopping-svc/estargz/v0.18.2 and entities/shopping-svc/ipfs/v0.18.1, point at the exact same commit (204b1d6) - that commit changed estargz and left ipfs untouched since its prior release, so ipfs’s existing tag and estargz’s new one both land there. I confirmed both resolve correctly and separately, live, against the real repo:

$ go list -m github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/estargz@v0.18.2
github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/estargz v0.18.2

$ go list -m github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/ipfs@v0.18.1
github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/ipfs v0.18.1

Same commit, two distinct, correctly identified modules, because each resolves through its own module path’s expected subdirectory and its own go.mod. The tag got you to the commit. After that, it’s gone - nothing in go.mod, go.sum, or a compiled binary ever refers back to the tag string again, only to the resolved version and content hash. You could rename every tag in this repo tomorrow and none of these modules’ identities would change.

Bonus: a GOPROXY you can hold in your hand

One more piece, kept short on purpose. The producer repo has a small Go program, tools/goproxy-gen, that generates a real, static implementation of the Go module proxy protocol - @v/list, @v/<version>.info, @v/<version>.mod, @v/<version>.zip, @latest - directly from this repo’s own tags. It’s built entirely on the official golang.org/x/mod packages: modfile to discover modules, a from-scratch exact-semver regex to find each module’s real tags (informed by the same hyphen bug from the release workflow), and zip.CreateFromVCS to build each version’s zip straight from Git history. That last function is worth calling out on its own: it automatically excludes nested modules from the zip - shopping-svc’s archive never contains estargz/ or ipfs/ - using the same module-boundary rule this whole post has been about, because it’s the real Go toolchain’s own logic, not something I had to reimplement.

A GitHub Actions workflow runs this on every push to main, resolves all four modules through the freshly generated tree with a real go get as a sanity check, and uploads the result as a build artifact. Point GOPROXY at the unzipped artifact and every command in this post works with zero network access and zero GitHub - which is a genuinely useful trick for air-gapped CI, not just a demo.

Try it yourself

Everything here is copy-pasteable against the real repositories:

# Clone and run the producer's own service via go.work
git clone https://github.com/abhi4u1947/go-multimodule-poc.git
cd go-multimodule-poc
go run ./entities/shopping-svc/cmd/shopping

# Clone the consumer and run it as-is
git clone https://github.com/abhi4u1947/go-multimodule-poc-consumer.git
cd go-multimodule-poc-consumer
go run .

# Pull one specific version of one specific nested module
go get github.com/abhi4u1947/go-multimodule-poc/entities/shopping-svc/estargz@v0.18.1
go mod tidy

# See what actually got selected, versus what was asked for
go list -m all
go mod graph

I ran each of these against the live repositories on Go 1.24.7 while writing this. Module resolution details - pseudo-version shape, exact error text, MVS output formatting - can shift slightly across Go releases, so if something on your machine looks a little different, check the version with go version first and cross-reference go.dev/ref/mod before assuming the mechanism changed.

Where this leaves us

That teammate’s go get failure from the top of this post was a tag missing its directory prefix - a bare v1.0.0 where the tooling needed entities/shopping-svc/v1.0.0. Small mistake, and completely invisible until someone tries to pull the module from outside the repo.

A nested module’s tag must carry its full directory path, or it doesn’t exist as far as go get is concerned. Not close, not fuzzy-matched - exact.

A nested go.mod is a hard wall. ./... stops there, in both directions, no configuration involved.

Minimal Version Selection means the ceiling of everyone’s floor, not the newest tag in existence. Read go list -m all for the outcome, go mod graph for who asked for what.

go.work and replace solve the same local-development problem from two different vantage points, and neither one ever leaves your own machine - consumers never see either.

The module line in go.mod is a module’s entire identity. The tag that found it is disposable the instant the commit is resolved.

If you’re carrying more than one Go module in a repository, or about to start, that’s the whole rulebook. I’d rather you learn it from this post than from a teammate’s confused Slack message about a tag that “should” be there.

For the kind of work I described in my scoping post, that’s acceptable in the short term because I constrained access at the RBAC level. RBAC-only is not workload identity though. It’s a permission boundary with no traceability. When I’m running agents in environments that matter, I want what I’d want for any other workload: cryptographic identity, short-lived credentials, a clear audit trail.

SPIFFE is the framework I’d reach for first. I’ve used SPIRE to issue workload identity for service meshes - mTLS between services, JWT-SVIDs for cross-cluster API calls, workload attestation tied to k8s pod metadata. The question I’ve been sitting with: does the same model transfer to agent workloads?

Partly. Here’s where I’ve landed.

What SPIFFE/SPIRE actually does

The quick version, for readers who haven’t wired it up. SPIFFE defines a standard for workload identity: each workload gets a SPIFFE ID in the format spiffe://<trust-domain>/<path>, and a SVID (SPIFFE Verifiable Identity Document) that proves it. SPIRE is the reference implementation that issues and rotates them.

Two SVID types matter here:

• X.509-SVIDs are TLS certificates. They enable mTLS - mutual authentication where both sides prove identity. TTL defaults to 1 hour; SPIRE auto-rotates via a streaming Workload API connection, so workloads get fresh certs before expiry without polling.
• JWT-SVIDs are signed tokens with mandatory aud (audience) and exp (expiry) claims (per the SPIFFE JWT-SVID spec). Short-lived, single-audience. Better for discrete API calls where you want to scope the credential to one downstream service.

Attestation is how SPIRE knows a workload is who it claims to be. Node attestation verifies the underlying host: cloud instance identity documents, k8s projected service account tokens, TPM. Workload attestation verifies the process: Unix UID/GID, k8s pod metadata, docker labels, systemd unit name. The combination gives you: this specific process, running in this specific pod, on this specific node, with this specific identity.

Where it fits for agents

An agent binary running in a known environment attests cleanly with existing SPIRE selectors. A Goose process in a k8s pod gets a SPIFFE ID like spiffe://prod/agents/goose-worker, backed by a certificate issued to that pod’s identity. It auto-rotates. Any internal service configured to trust the same SPIRE server can verify it.

For tool calls specifically, JWT-SVIDs with audience binding are a real improvement over long-lived API keys. Instead of a static GITHUB_TOKEN sitting in the environment, the agent requests a JWT-SVID with aud: github-proxy before each call - short-lived, audience-scoped, auditable on the receiving end by checking the aud claim. The receiving service sees exactly which SPIFFE ID made the call and when.

I’ve done this for batch jobs calling internal services. The setup transfers directly to a Goose process running in a pod.

The session identity gap

Here’s where it gets complicated. SPIFFE’s attestation model is process-centric. The SVID belongs to the running process. One agent binary can run hundreds of sessions over its lifetime - from SPIFFE’s perspective, they’re all the same workload.

Three things break when you need session-level accountability:

The audit trail problem. Your API gateway log shows spiffe://prod/agents/goose-worker called kubectl get pods 47 times. You can’t tell which session produced each call, which user prompt triggered it, or what chain of reasoning the model was following when it ran. For incident investigation, that’s not enough. For compliance, it’s useless. This is the same gap I named in the supply chain post – no attestation connecting executed commands back to the reasoning that produced them.

The blast radius problem. If a session goes wrong - prompt injection, bad tool call, a model that decided to kubectl delete something it shouldn’t - you can’t revoke that session’s credentials independently of the agent process. Revoking the SVID kills all active sessions on that agent. You’re choosing between “leave the compromised session running” and “take down everything.”

The subprocess identity problem. When Goose spawns a shell tool that calls aws s3 ls, that subprocess is not the attested workload. It inherits the parent’s environment. The Workload API socket binding is to the agent PID; child processes get nothing from SPIRE. If the subprocess needs to authenticate to something, it’s back to environment-variable credentials.

SPIFFE gives you process identity. Agents need session identity as a first-class concept. JWT-SVIDs are the closest fit - short-lived, audience-bound, can carry additional claims - but SPIRE issues them for the process, not the session. Minting a fresh JWT with session-scoped claims requires custom logic above the SPIFFE layer.

What a session-identity layer looks like

A pattern I’ve been sketching sits on top of SPIFFE rather than extending it. The rough shape:

1. Process attestation via SPIRE. The agent binary gets a SPIFFE X.509-SVID the standard way - workload attestation, auto-rotating, 1-hour TTL. This is the base credential: it proves the agent is what it claims to be, running where it claims to be running.

2. A session minting service. A lightweight internal service, itself identified via SPIFFE, that issues session tokens. At session start, the agent presents its process SVID and gets back a short-lived JWT with session-scoped claims: session_id, user_id, initiated_at, allowed_tools[], max_ttl. The session JWT is signed by the minting service’s key, not SPIRE’s. TTL is per-session policy. A receiving service that enforces allowed_tools[] rejects calls to any tool not in the session’s approved list – so a session scoped to read-only Kubernetes access literally cannot call an AWS or GitHub tool, even if the agent process has those MCP servers configured. The minting service populates this claim at session start based on the session’s declared scope, which can be derived from the user prompt, a session policy file, or both.

3. Session JWT on all tool calls. Every downstream call carries the session JWT as a bearer token. The receiving service validates it against the minting service’s public key, extracts the session_id, and logs it. The audit trail is now session-granular, not process-granular.

4. Minting service as revocation point. To kill a session, you invalidate its session_id at the minting service. Other sessions on the same agent process are unaffected.

This is not SPIFFE. It’s a pattern that uses SPIFFE for base attestation and adds the session layer on top. I’ve built analogous things for batch job pipelines that needed per-job credential scope; the mechanics are the same, the agent-specific claims (allowed_tools[], initiated_at) are new.

The piece I haven’t solved: subprocess identity. Getting a spawned shell tool to carry the session JWT rather than fall back to environment credentials requires either a wrapper that injects the JWT into the subprocess environment, or an MCP server that brokers all tool calls through the session-aware layer. The second option is cleaner but requires more infrastructure. I want to prototype both before recommending one.

What the ecosystem needs

SPIFFE and SPIRE are the right foundation. Platform-agnostic attestation, auto-rotating credentials, a standard Workload API - all of it transfers cleanly to agents at the process level.

The missing piece is session identity as a standard abstraction rather than a custom per-deployment pattern. What would help: a SPIFFE profile for agentic workloads that formalizes session token minting on top of SVIDs - the same way the existing k8s and AWS profiles define how attestation works in those environments. An “agent session” profile could specify the minting exchange, the required JWT claims, and the revocation mechanism, so every platform team doesn’t have to design this from scratch. This is the kind of standardization work that belongs at a neutral body – CNCF’s successor to TAG Security, or the AAIF working groups already convening around agent standards – rather than re-invented by every platform team.

I’m planning to prototype the session minting pattern in a future post - a real SPIRE setup, a real minting service, a real Goose session where every tool call carries a verifiable session JWT. I want to see where the subprocess identity problem bites in practice before writing up the solution.

If you’re already working on something in this space, reach out.

Open Plugins is trying to fix that.

The distribution problem

The agent tooling ecosystem has a packaging gap. We have MCP for the protocol, AGENTS.md for behavior declarations, and a growing catalog of Goose extensions - but no standard answer to the question: how does a plugin get from the author’s repo to a running agent, in a way that’s reproducible, inspectable, and safe to do on a shared machine?

That gap is what Open Plugins is addressing. The spec defines a convention-based system for discovering, packaging, installing, and namespacing agent extensions. It covers skills, commands, agents, hooks, MCP servers, and LSP servers - essentially everything that runs alongside an agent and extends its capabilities. The goal is that any conformant agent tool can install and run any conformant plugin, without custom integration work on either end.

How the standard works

At its core, a plugin is a directory with a predictable layout. A plugin manifest lives at .plugin/plugin.json and declares the plugin name plus any non-standard component paths. The manifest is optional - if a plugin follows the directory conventions, a conformant tool can discover everything without it.

Component discovery uses these default paths:

• Skills: /skills/*/SKILL.md
• Commands: /commands/*.md
• Agents: /agents/*.md
• Hooks: /hooks/hooks.json
• MCP Servers: /.mcp.json
• LSP Servers: /.lsp.json

Installation copies the plugin to a local cache directory and adds it to the enabledPlugins list in the tool’s settings. Plugins are expected to be self-contained - no external dependencies resolved at install time.

Path references inside the plugin use a ${PLUGIN_ROOT} placeholder that expands to the plugin’s absolute path after installation. Hook commands, MCP configs, and LSP settings all use this mechanism. It’s the same problem npm solved with __dirname, and the Open Plugins answer is correct: lock the root at install, expand everywhere.

Namespacing uses a pluginName:componentName format. A deploy-tools plugin’s status skill becomes deploy-tools:status. This prevents collisions when multiple plugins expose components with the same name.

The spec ships with a reference CLI: npx plugin-ref validate ./my-plugin checks conformance, npx plugin-ref inspect shows what a tool would discover. Shipping a validator alongside the spec is exactly the right call.

Specs without reference implementations drift.

What it gets right

Convention over configuration is the right default here. The manifest is optional, and the directory conventions are simple enough that most plugin authors will follow them without thinking about it. Adoption requires zero friction for the common case; Open Plugins mostly delivers that.

The minimal conformance requirements also help. A conformant tool only needs to handle one component type; it doesn’t have to implement the full spec to be useful. That’s a pragmatic choice for a young ecosystem where adoption matters more than completeness.

The ${PLUGIN_ROOT} expansion solves a real portability problem. Without it, plugins either hardcode absolute paths (breaks on any machine that isn’t the author’s) or use relative paths (breaks when the plugin gets copied to a cache directory). The expansion mechanism is clean, and the path traversal protection - ../ sequences that escape the plugin root are rejected - is the right boundary.

Namespacing is underrated. I’ve already had skill name collisions in my Goose setup. Having a canonical format for disambiguation is going to matter once there are hundreds of plugins in circulation.

The security questions it still needs to answer

This is where I put my platform-security hat on, and where I want to be careful to separate “this is wrong” from “this is appropriate for where the ecosystem is, and here’s what needs to happen next.”

The current trust model is roughly: install the plugin, hooks and MCP commands run with your user-level permissions, and the recommended mitigations are advisory. That’s not a critique of the spec authors - it’s the same pragmatism that got npm to adoption in 2010. But it’s worth naming the gaps precisely, because this is the point in the ecosystem’s lifecycle where they’re cheapest to fix.

The specific gaps I see:

Hook execution at user level, with advisory mitigations. A plugin’s hooks run as the installing user. The spec recommends sandboxing, allowlisting, and user confirmation before enabling hooks - but these are implementation guidance, not conformance requirements. A tool that installs plugins and runs hooks with none of those controls is still conformant. The threat surface is roughly equivalent to curl | bash, and the spec treats it as a UX choice rather than a security boundary.

No signing story. Nothing in the current spec tells a conformant tool how to verify that a plugin came from who it claims to come from. A release could be tampered with between the author’s repo and a user’s machine, and a conformant tool has no way to detect it. This is the same gap npm had in 2012.

No SBOM. A plugin’s /.mcp.json can reference a remote MCP server. That server has its own dependencies, its own update cadence, its own author. The “self-contained” requirement covers the plugin package itself, but the MCP servers it configures are effectively untracked transitive dependencies. There’s no standard way to produce or consume a software bill of materials for a plugin.

Path traversal protection as guidance, not requirement. The spec says implementations should reject ../ sequences that escape the plugin root. I’d like to see this as a must. “Should” in a security control means “optional in practice.”

I raised similar questions in my supply chain post about the MCP ecosystem in general. Open Plugins makes those questions concrete. Here’s the spec. Here are the specific places where the supply chain story is thin.

Why the timing matters

The standard is early. That’s the good news.

npm shipped without package signing in 2010. Sigstore-based provenance support arrived in 2023 – thirteen years later – and still isn’t universally enforced. Thirteen years of retrofitting security into an ecosystem that had grown around the gaps. The JavaScript community is still paying for decisions made when npm was a side project.

Open Plugins is at the beginning of that curve. Open Plugins is not currently an AAIF project – it is maintained by Vercel Labs – but the AAIF community is exactly the right group to adopt and endorse these norms before the ecosystem grows around the absence of them. Goose, MCP, and AGENTS.md already have the Linux Foundation governance structure and the audience that cares about supply chain security. The tooling (Sigstore, in-toto, CycloneDX) exists. The question is whether the spec reaches for it before the install base gets large enough to make breaking changes painful.

What I’d like to see

Concrete asks, in rough priority order:

• Signing for plugin releases. Sigstore-style, with a transparency log the community can verify. The plugin-ref CLI already validates structure; a plugin-ref attest subcommand that checks signatures would be a natural extension. Make signature verification a conformance requirement for enterprise-tier tools, advisory for community tools.
• An SBOM requirement for plugins that reference external MCP servers. CycloneDX or SPDX format, generated at build time, included in the plugin package. Not optional for any plugin that ships a /.mcp.json.
• A trust-level field in the manifest. Something like community, verified, enterprise that conformant tools surface to users before installation. The details can be worked out - the point is that install should not be binary.
• Path traversal as a conformance requirement, not a recommendation.

None of these are blockers for adoption today. They’re the difference between a standard that enterprises can reference in a security policy and one that stays in developer-only workflows.

I’m planning to prototype some of this - signing a plugin release, generating an SBOM for a Goose configuration. If you’re working on any of it already, reach out.

The standard is worth engaging with seriously. That’s why I’m raising the gaps.

Then I started using Goose and connecting it to MCP servers – first in the scoped ops setup I wrote about last week – and I realized none of that thinking has been applied here yet.

Almost every post you can find on MCP frames it the same way: MCP is the USB-C of AI integrations. Plug in any server, your agent gains capabilities. It’s slick, it’s growing fast, and 70+ extensions exist for Goose alone.

What nobody seems to be writing about: every MCP server you install is code from somewhere, running in your environment, with tools your agent will invoke based on natural language reasoning produced by an LLM. From a supply chain perspective, that is not a small surface.

Let me try to name the questions, because I think we need to start asking them out loud.

What “supply chain” even means for an agent workflow

When a Goose session does something - say, “find the drift between our Terraform state and the AWS console” - the chain of things that produced that outcome looks roughly like:

1. The model. A specific LLM, with a specific version, behind a specific API. Its training data, its safety tuning, its tool-calling behavior - all part of what shaped the output.
2. The agent code. Goose itself: Rust binary, version-pinned, signed (or not) at distribution.
3. The MCP servers. Each one is its own piece of software, running locally or remote, with its own dependencies, its own update cadence, its own author.
4. The tool definitions. The schema and natural-language descriptions exposed by each MCP server, which the agent uses to decide what to call.
5. The natural-language reasoning produced by the model and conditioned on a prompt - yours, the system prompt, and any context retrieved during the session.
6. The commands executed, which are downstream of all of the above.

In a traditional CI/CD pipeline, we’d want provenance for every step. Here, we mostly have it for step 2 (the agent binary) and not much else.

The questions I think we should be asking

Some of these are solvable today with existing tooling applied to a new context; others require new conventions that don’t exist yet. I’ll call that out as we go.

Provenance for MCP servers

When I add an MCP server to my Goose configuration, I’m adding code that will run on my machine and decide which of my files, APIs, and credentials to interact with. Right now, the equivalent of pip install for MCP servers - goose configure and add the path or URL - has roughly the same security model as curling a bash script and piping to sudo.

The questions:

• Who signed this MCP server’s release? Is the signature checkable? Is there a key transparency mechanism?
• What’s the source-of-truth repo, and has the binary I’m running been built from the commit it claims?
• What dependencies did it pull in at build time? Where’s the SBOM?
• If the server is remote, what’s the attestation that the running instance matches the published source?

Sigstore, SLSA, and in-toto have made enormous progress on these questions for traditional artifacts. As far as I can tell, none of that has been threaded through the MCP ecosystem yet.

Attestation for tool calls

When an agent calls a tool - kubectl get pods, or an MCP server’s read_file - that call should ideally be attestable. We should be able to say, after the fact: this command was issued by this agent, in this session, under this user, with this set of arguments, and the model’s stated reasoning was X.

We have most of the building blocks. Goose can already produce session logs. MCP servers can produce structured records of their tool invocations. What I haven’t seen is a coherent attestation format that ties them together in a way that survives later audit.

This matters for the same reason audit logs matter for human admins: when something goes wrong in production, you want to be able to reconstruct who or what did it.

The prompt as a build artifact

A working agent session is partly defined by its prompts - the system prompt, the user prompts, any retrieved context. From a supply chain view, the prompt is closer to source code than it is to configuration. It determines behavior. It should probably be versioned, reviewed, and signed.

I don’t see any serious treatment of this yet for production agentic systems. Most prompt management tooling today is product-focused (analytics, A/B testing) rather than supply-chain-focused (provenance, review, audit). This one requires new conventions, not just new tooling applied to a new context.

The model as a dependency

If my Goose session calls Anthropic’s Claude, OpenAI’s GPT, or a local Llama via Ollama, each of those is, in supply chain terms, a dependency. Different versions of the same model can behave meaningfully differently. Switching providers mid-session can produce different outputs from identical prompts.

We do not currently have anything resembling a version-pinned, attested model dependency in most real deployments. We have model names, sometimes with version suffixes, often without. That’s not enough. Like the prompt question, this one requires new standards work – there is no existing tooling to apply here.

Why this matters now, not later

Two reasons.

First, the agentic AI ecosystem is at a critical moment. Goose and MCP are growing fast and being adopted by real teams. The standards we set now - or fail to set - are the ones that get baked in. We did this badly with npm and the JavaScript ecosystem in the 2010s, and we’re still paying for it. We have a chance to not repeat that here, because the AAIF projects are open source, they’re hosted at the Linux Foundation, and the audience that cares about supply chain security knows what good looks like.

Second, agents make the consequences worse, not better. A traditional pipeline executes deterministic code. An agent pipeline executes the output of natural-language reasoning conditioned on tool descriptions written by people you didn’t vet. If your supply chain has gaps now, agentic AI will exploit them at machine speed.

What I’d love to see

I’d love to see the AAIF community - Goose, MCP, AGENTS.md - start treating supply chain security as a first-class concern, not a “later” item. Specifically:

These aren’t competing solutions – they’re a stack. Sigstore handles signing and key transparency. in-toto attests the pipeline steps. SLSA provides the level framework for what “attested” means at each stage. CycloneDX provides the artifact inventory format. Used together, they give you the same supply chain posture for agentic workflows that mature CI/CD pipelines already have.

• An SBOM standard for MCP servers, with CycloneDX or SPDX format, generated at build time.
• Sigstore-style signing for MCP server releases, with a trust root the community can verify.
• in-toto attestation for agent tool invocations, with a structured format that integrates into existing supply chain tooling.
• A reference implementation of an “agentic supply chain” - Goose configured with attested MCP servers, producing signed session logs, integrated into an SLSA-style provenance chain.

Some of this exists in pieces, in adjacent ecosystems. None of it is wired together yet for agentic AI specifically.

I’m going to start prototyping some of this in upcoming posts. Pinning MCP servers to specific signed releases. Generating SBOMs for Goose configurations. Producing structured session attestations. The next post looks at the Open Plugins standard – the first concrete attempt at a distribution spec for agent extensions – and asks these same questions of a specific artifact.

If anyone is working on this already, please reach me - about page has my coordinates. If you’re at AAIF and reading this, I’d love to talk about whether any of this is on the roadmap.

A note on tone

I’m aware this post is more “raising questions” than “providing answers.” That’s deliberate. I’ve seen too many supply chain conversations get derailed because someone showed up with a half-built solution before the community had agreed on the problem. The point of this post is to put the problem on the table for the agentic AI community in the language platform-security people speak.

If we can agree the questions are worth taking seriously, the answers will follow.

I’m an architect. That question is the entire interesting part for me. So this post is the inverse of the usual tutorial - it spends most of its words on the configuration, not the demo. The demo is at the end and is honestly the less important section.

TL;DR: Before letting Goose touch anything real, scope its access through a dedicated service account with read-only RBAC, run it in a working directory it can’t escape from, and treat the boundary between “investigate” and “apply” as something enforced by IAM, not by trust in the agent’s judgment.

The threat model I’m working from

Goose is a local agent with shell access and MCP-based tool integrations. From a platform-security perspective, that means:

• Anything in my shell environment is in scope for the agent.
• Anything my user can do, the agent can attempt.
• Anything the configured MCP servers can do is part of the agent’s reach.
• The LLM behind it can produce confidently wrong commands. It will eventually do this. Plan for it.

The boundary I want is roughly the boundary I’d want for a competent junior engineer on their first week: investigate freely, propose changes, but apply nothing to shared infrastructure without a human in the loop. The way I enforce that boundary should not depend on the agent following instructions - it should be enforced where the credentials live.

The setup

For this session I configured Goose to triage a misbehaving service in a staging Kubernetes cluster. Here’s the full configuration, with reasoning.

1. A dedicated service account with read-only RBAC (Kubernetes RBAC docs)

I created a dedicated service account in the cluster, scoped to a single namespace, with read-only permissions:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: goose-triage
  namespace: staging
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: goose-triage-readonly
  namespace: staging
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log", "events", "configmaps", "services", "endpoints"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets", "statefulsets"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["metrics.k8s.io"]
    resources: ["pods"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: goose-triage-binding
  namespace: staging
subjects:
  - kind: ServiceAccount
    name: goose-triage
    namespace: staging
roleRef:
  kind: Role
  name: goose-triage-readonly
  apiGroup: rbac.authorization.k8s.io

I then generated a dedicated kubeconfig pointing at that service account’s token, scoped to that namespace, with current-context already set. No admin context, no other clusters, no other namespaces.

This took maybe ten minutes. If you skip this step, you’re not using an agent - you’re using a very fast autocomplete with root.

2. A scoped working directory

I created ~/goose-sessions/triage-2026-05-22/ and launched Goose from there. The Developer extension’s shell tool can run anywhere your user can, so the right move is to give it a directory that doesn’t have your dotfiles, SSH keys, or git credentials in scope of its working set.

3. An explicit prompt about boundaries

I started the session with this:

You have a read-only kubectl context configured (KUBECONFIG=./kubeconfig-goose-triage).
You have shell access in this working directory.
You do not have permission to apply any changes to the cluster, modify any files
outside this directory, or take any actions that affect shared infrastructure.

When you identify a likely root cause or recommend a fix, summarize it for me
to review - do not attempt to apply it yourself, even if you think the read-only
context will prevent harm.

Walk me through your reasoning before running each command.

The “walk me through your reasoning before running each command” line is important. Without it, Goose will sometimes batch 4-5 commands together and present results. Faster, but harder to interrupt when the reasoning is going somewhere wrong.

The session

The actual investigation took about 12 minutes. I’m going to summarize rather than paste the whole transcript, since the configuration is the part that’s worth your time.

The scenario: a Node.js service in the staging namespace had been crash-looping for two weeks. Standard “we keep meaning to look at this” backlog item.

What Goose did:

1. kubectl describe and kubectl logs --previous on the pod. Standard. Found Last State: Terminated, Reason: OOMKilled.
2. Pulled the deployment manifest. Noted limits.memory: 512Mi.
3. Inspected the container’s command: node index.js. Noted no --max-old-space-size flag.
4. Inferred - correctly - that V8 was sizing its heap from the host’s total visible memory rather than the container’s cgroup limit – Node.js doesn’t read cgroup boundaries by default – so the OOM killer fired before V8’s garbage collector got aggressive.

That inference is the interesting one. I knew the V8/cgroup interaction existed in theory but hadn’t connected it to this pod. Goose got from “OOMKilled” to “V8 doesn’t respect container limits unless you tell it to” in about 90 seconds. I’d estimate I’d have spent 20-30 minutes on it, starting from a different hypothesis (queue consumer memory leak).

Where I had to step in: Goose suggested patching the deployment to add --max-old-space-size=384 (Node.js CLI docs). The suggestion was reasonable. Two reasons I didn’t let it try:

1. The real fix lives in our GitOps repo, not in kubectl edit. A patched cluster that drifts from git is a worse problem than the OOM.
2. 384Mi is a guess. The right number comes from actually profiling heap behavior under load.

I asked Goose to write a one-paragraph summary I could paste into a Jira ticket. It did, accurately.

What I learned about scoping

A few things were clearer to me after this session than before:

The read-only boundary is the whole game. Not because I expect Goose to act maliciously, but because the moment “investigate” and “apply” become the same operation, you’ve lost the ability to keep a human in the loop. RBAC enforces this whether the agent agrees with it or not. That’s the property I want.

The “walk me through your reasoning” prompt matters. It’s the difference between an agent and an opaque oracle. It also produces text I can paste into a ticket or runbook, which is real ongoing value beyond the one session.

Don’t let the agent write to shared state, ever. Even with read-only RBAC, the agent could in principle write to your local filesystem in ways that affect later sessions. Use a fresh working directory per session, or at minimum understand which files in your environment are reachable.

The MCP integration is where this gets interesting and scary. Goose’s power comes from the 70+ MCP extensions it can talk to. Each one is a new permission surface. If you add an AWS MCP server, you now need to think about IAM policies on the role its credentials use. If you add a GitHub MCP server, that’s a token with some scope attached that the agent can invoke on your behalf. The right mental model is not “I’ve secured Goose” – it’s “I’ve secured this specific set of MCP integrations for this specific session.” Most of this isn’t documented yet. I go deeper on the supply chain angle in the next post.

A checklist I’m settling on

For anyone running Goose on infrastructure that matters:

1. Dedicated service account per session type, with the minimum RBAC for the workflow.
2. A dedicated kubeconfig, not your daily-driver one, with the SA token and a single context.
3. A scoped working directory, ideally inside a container or VM if you’re paranoid.
4. An explicit boundary prompt that names what the agent can and can’t do.
5. A “summarize, don’t apply” rule for any change to shared infrastructure.
6. Audit logs. If your platform doesn’t yet capture what the agent did, that’s the next project after this one.

What’s next

I want to do the same kind of writeup for a few other workflows: Terraform drift detection (the agent investigating against a real cloud account), CI pipeline triage, and the supply chain question - how do you treat MCP servers as part of your software supply chain?

If you have an ops workflow you’ve been curious whether Goose could help with - especially anything platform-engineering-shaped - tell me. I’ll add it to the queue.

The Goose docs cover the basics. The AAIF Discord is where the real conversations happen. I’m @abhi4u1947 in #goose.

When I look at the current wave of agentic AI tools, I don’t see them the way most of the writing about them frames them. I don’t see “a smart assistant for developers.” I see a new class of workload - one that will run inside the platforms I help build, with all the IAM, audit, observability, supply-chain, cost, and governance questions that implies.

That perspective is largely missing from the agentic-AI conversation. I want to add it.

What’s missing from the existing writing

If you search for tutorials on Goose - the open-source agent now hosted by the Agentic AI Foundation at the Linux Foundation alongside MCP and AGENTS.md - you’ll find a lot of the same post. Install Goose. Ask it to write a Python script. Watch it generate code. Marvel at the AI. The framing is consistently “Goose is an AI coding assistant.”

That’s accurate, but it’s the least interesting thing about it. Goose is something rarer:

A local agent with a real shell, real filesystem access, and a growing stack of MCP integrations - that can be pointed at production-adjacent infrastructure and asked to do real work.

That’s not a Copilot. From a platform architect’s seat, that’s a new kind of workload identity problem. A new kind of audit trail problem. A new kind of supply chain question - because if my pipelines are now executing reasoning produced by an LLM that called MCP servers I didn’t write, what does provenance even mean here?

When Goose calls kubectl exec through an MCP server, the Kubernetes audit log records my user identity - not the agent’s, not the session’s, not the tool call that triggered it. There is no provenance connecting that API call back to the model reasoning that produced it. That’s the gap.

And the gap is no longer purely conceptual. The specs and tooling to close it have started landing - fast - and most of the platform community hasn’t caught up.

What the last six months brought

Three things converged in the last six months that change how this conversation should be framed:

1. The Agentic AI Foundation formed at the Linux Foundation in December 2025, with platinum support from AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. MCP, Goose, and AGENTS.md are now under neutral governance. That removes the “which standard do we bet on” objection that was slowing enterprise adoption.

2. Agent identity moved from blog posts to IETF drafts. In March 2026, draft-klrc-aiagent-auth-00 was published, composing the IETF WIMSE working group’s work with SPIFFE and OAuth 2.0 into a framework called AIMS (Agent Identity Management System). Separately, Dick Hardt (author of the original OAuth 2.0 RFC) has been developing aauth.dev - a specification that treats agents as first-class identities rather than as OAuth clients known at build time. The MCP authorization spec itself, built collaboratively with Anthropic, Microsoft, Okta/Auth0, Arcade.dev and others, now defines OAuth-style protected resources with audience binding via RFC 8707 resource indicators and delegation via RFC 8693 token exchange. That last bit matters a lot - and I’ll come back to why.

3. Microsoft shipped APM - Agent Package Manager. One apm.yml, every harness, every machine. Lockfiles with content hashes. A policy file (apm-policy.yml) enforced at install time, including for transitive MCP servers. Tighten-only inheritance from enterprise to org to repo. This is the first piece of agent infrastructure that looks like it was designed by someone who has actually run an enterprise software supply chain program. It maps cleanly onto the SBOM / SLSA / in-toto thinking I’ve been doing for years - but applied to an entirely new artifact class: skills, prompts, plugins, and MCP server bindings.

4. The extension and skills layer is taking shape. The Agent Skills Specification defines a standard for how agents declare, discover, and invoke reusable capabilities across harnesses. Alongside it, the Open Plugins standard covers packaging and distribution - skills, commands, agents, hooks, and MCP server bindings as installable, namespaced artifacts with content-addressed lockfiles. Together they form a skills layer that sits between the protocol (MCP) and the identity layer (AIMS) - and it’s the missing middle of the emerging platform stack that neither MCP nor APM fully addresses on its own.

The conversation about agents is no longer “look what it can write.” It is: how do we identify them, how do we package them, how do we govern them, and how do we keep them from setting our cloud bill on fire? Those are platform engineering questions.

How I got here

A few years ago I started looking seriously at how AI was actually getting wired into enterprise SDLC pipelines. At Amdocs I integrated OpenAI’s GenAI into developer workflows and saw how quickly the conversation moves from “this is interesting” to “this is in production, who owns the failure modes?” I wrote about adjacent topics on LinkedIn in late 2024 - the CNCF End User Reference Architecture, NIST’s post-quantum cryptography work - but agentic AI specifically needed a different format. Long form, with code, configs, and references to the actual specifications. Somewhere I could think out loud.

So this site.

What I’m planning to write

The questions cut across the whole agentic AI stack. Here are the threads, with the actual specifications and projects each one touches - because none of this exists in isolation anymore.

Identity and delegation: the unsolved problem

OAuth 2.0 was designed for clients known at build time. Agents are not that. They make runtime decisions, spawn sub-agents, and traverse trust boundaries. The cracks are visible.

The interesting question isn’t “can we authenticate an agent.” SPIFFE/SPIRE solved workload identity for non-human callers years ago, and the CNCF’s 2026 recommendation for service-to-service auth is now explicitly “SPIFFE for identity, OAuth 2.0 for access delegation, OPA for policy.” The hard problem is delegation chains. When an orchestrator agent spawns a sub-agent that calls a tool that calls an external API, under whose authority is the final action taken? Does a user’s consent to the orchestrator flow automatically to the sub-agent? To what depth? Can a sub-agent end up with more permissions than its parent?

RFC 8693 token exchange supports nested delegation, but the IETF OAuth WG formally documented a delegation-chain-splicing weakness in early 2026, and the AIMS draft is solid on authentication but explicitly weaker on delegation. That gap is where the real platform-engineering work lives - and it’s where almost nothing is written from the perspective of someone who’s actually run an IAM program at scale. I want to write that.

Software supply chain: from SBOM to agent manifests

I’ve spent the last year embedding SBOM (CycloneDX), SLSA provenance, and in-toto attestation into release pipelines at Netcracker, with measurable results - issue detection up to six months pre-release, CVE-driven redeployments cut in half. That mental model maps almost too cleanly onto Microsoft’s APM.

An apm.yml declares agent dependencies - skills, plugins, MCP servers, agent primitives - and the lockfile pins content hashes so a clone reproduces byte-for-byte. apm-policy.yml is enforced at install time, including for transitive MCP servers, with tighten-only inheritance. That last property is exactly the design pattern enterprise security teams asked for, and almost never got, in package manager history.

But agent manifests open new questions a normal SBOM doesn’t touch:

• What’s the equivalent of SLSA build provenance for a skill - a file containing prompts and instructions that change agent behaviour?
• How do you attest the integrity of an MCP server when its surface area is a set of tools, each with permissions implications? CVE scanning doesn’t cover “this tool can kubectl delete pod.”
• Hidden-Unicode injection is now a baseline scan in APM. What’s the equivalent for skill instructions that don’t trigger normal lint?
• And the research is already pointing in uncomfortable directions: a 2026 study by Gloaguen et al. on 138 real-world repositories found that LLM-generated AGENTS.md files reduce task success and inflate inference cost by over 20%. The agent follows the file faithfully. If your supply chain ships skills generated by another LLM, your performance and cost regression isn’t a bug - it’s a property of the artifact.

Cost: the single biggest production problem in 2026

This is the question nobody was asking eighteen months ago and that everybody is asking now. Deloitte’s 2026 tokenomics work has finance leaders treating AI spend with the rigor they used to reserve for energy or capital. Gartner predicts more than 40% of agentic AI projects will be cancelled by the end of 2027 - and the cited reasons are cost, unclear business value, and inadequate risk controls. None of those are model problems.

The specific failure modes I’ve seen referenced in production retrospectives:

• Token maxing. Defaulting to the most capable model for every task, with no routing logic. One healthcare enterprise reportedly consumed a trillion tokens in six months - over $6M unplanned - before finance understood what was driving it.
• Orchestration loops. A LangChain multi-agent system ran an infinite loop for eleven days before being noticed. The bill: $47,000.
• Context bloat. Naive memory injection scales linearly; production traces hit 80-120K token contexts within two to three weeks.
• Tool definition tax. MCP tool metadata can consume 40-50% of the context window on every call, regardless of relevance.

The platform answer isn’t “pick a cheaper model.” It is structural: model routing layers, per-workflow token budgets, prompt caching for stable system prompts, hierarchical multi-agent topologies (frontier model for the orchestrator, cheap models for workers - published architectures hit ~97% of full-frontier accuracy at ~61% of the cost), and hard iteration caps on every agent loop.

This is where platform engineering earns its keep. “Cost is an architectural concern, not an operational one” - that’s the right frame, and it’s the natural extension of the FinOps work platform teams have already been doing on cloud spend.

Harness engineering: the new layer

This is the discipline that didn’t have a name two years ago.

In phase one (~2022-2023), the conversation was prompt engineering. In phase two (2024-2025), context engineering - feeding the model the right files, project rules, and architectural constraints. The 2026 conversation is harness engineering: the non-model runtime that wraps the model with tool orchestration, verification loops, context management, guardrails, and observability. Mitchell Hashimoto put it bluntly: “Anytime you find an agent makes a mistake, you take the time to engineer a solution so that the agent never makes that mistake again.” Most of the time, that solution lives in the harness, not in the model.

The implication is significant for platform teams. As frontier models converge in raw capability, competitive advantage shifts away from which model and toward how good your harness is. That’s good news - it means the model layer becomes commoditised, business logic and guardrail rules live in your harness code, and lock-in becomes manageable. It also means platform teams now own a new layer in the stack: the deterministic execution loop that wraps a non-deterministic component.

I’ll be writing about what that looks like - and where today’s harness designs still have unsolved problems, particularly around the inferential controls (LLM-as-judge) that don’t behave like the computational ones (linters, tests, type checkers) we know how to reason about.

Multi-agent trust and A2A

Google’s Agent2Agent protocol, now under the Linux Foundation, defines how agents from different vendors discover each other (via /.well-known/agent.json Agent Cards) and exchange tasks over HTTP + JSON-RPC + SSE. MCP and A2A are complementary: MCP is how an agent connects to tools and data; A2A is how agents connect to other agents.

The trust questions multiply at A2A boundaries. When an Agent Card claims certain capabilities and authentication requirements, who attests that claim? When the orchestrator delegates to a third-party A2A agent that then calls its own MCP servers, what does the audit trail look like end-to-end? The Riptides work on SPIFFE-for-MCP and SPIFFE-for-A2A is one of the few honest attempts to answer this with a real implementation, not a slide deck - and it’s where I think the next two years of interesting standards work will happen.

Observability for agent workflows

Distributed tracing exists for microservices. What’s the equivalent for an agent that calls five tools, spawns a sub-task, modifies a file, and pauses for a six-hour async operation? OpenTelemetry has GenAI semantic conventions in progress, and a 2026 reverse-engineering of Claude Code’s architecture documented a five-stage progressive compaction strategy for context - that kind of internal state is mostly invisible to current tracing tools.

I led enterprise OpenTelemetry adoption at Amdocs and cut defect investigation time by 30% in microservices contexts. The agent-tracing problem is harder for reasons that should be intuitive to anyone who’s instrumented a stateful workload - but most of the published agent-observability writeups don’t engage with that depth.

Compliance and audit at scale

When agents run in production at volume, the audit trail question stops being theoretical. Today’s tooling still can’t tell you: which model reasoning produced which API call, under whose authorisation, with what context, through which chain of delegation. That answer exists for human users in mature IAM platforms. It does not exist for agents yet - not at the level of evidentiary quality a regulated industry actually needs. I want to map out what a real compliance story would look like, and what concrete things would need to change in the stack to support it.

Guardrails: layered, not bolted on

The framing I’ve found most useful, from the production retrospectives: AI accuracy first, then layered guardrails matched to business risk. Most teams add walls before optimising what the agent knows and how it reasons. That leads to brittle systems that are both expensive and unsafe.

The architecturally honest answer has three pillars: identity scoping (who/what can act, under whose delegation), runtime enforcement (policy at the gateway between agent and backend systems - OPA fits naturally), and behavioural monitoring (deviation detection over agent trajectories, not just output content filtering). Output filters like LlamaGuard solve a real but narrow problem; the harder one is unreasonable but technically permitted actions - what AgentDoG’s authors call the lack of agentic risk awareness in current guardrail models.

This is where platform teams and security teams need to converge, and it’s the cleanest argument I can make for why DevSecOps thinking maps onto agents better than pure ML-ops thinking does.

Real ops transcripts

Less abstract: incident triage sessions with Goose, including the parts where it was wrong and the parts where I had to override it. Configs that worked. Configs that broke production-adjacent things in interesting ways.

Platform engineering view

How agentic AI fits into an Internal Developer Platform. What changes about your golden paths. What new capabilities you’d want to expose as self-service - agent provisioning with bounded identity, scoped MCP server access, cost budgets, audit policy templates - and what you absolutely should not.

What I’m not going to do

• Write “the future of AI” essays. Other people are better at those.
• Pretend agents are magic. They are tools with failure modes. The failure modes are the interesting part.
• Ship demos that work in a sandbox and fall apart anywhere real.
• Treat the existing specs as either gospel or noise. AIMS, aauth.dev, the MCP auth spec, APM, A2A - each is a serious piece of work with real gaps. Engaging with them honestly is how the field gets better.
• Hide my mistakes. Twenty years in, I’ve made enough of them to know that writeups of failures are more useful than writeups of successes.

Who this is for

If you’re a platform engineer, architect, SRE, or DevSecOps person - this is for you. If you care about IAM, supply chain security, zero-trust, FinOps, or how to build platforms real teams actually adopt, you’ll find things here that aren’t on the agentic-AI hype circuit. Agentic AI is the current thread, not the permanent scope. The underlying interests - IAM, zero-trust, software supply chain, observability, Internal Developer Platforms - have been the work for twenty years. Agents are just the current place where those questions are getting harder, faster, and more interesting.

If you’re an AI researcher or an app developer looking for hot takes on model capability, this is probably not your blog. There are better people writing for you.

If the perspective here - agents as workloads, not assistants - is one you haven’t seen framed this way before, that’s the opening thread. Next: how I scoped Goose for production-adjacent work, what I locked down before letting it touch anything, what the APM manifests and policy files actually look like, and where the AIMS-style identity model breaks down when you try to apply it to a real delegation chain.

Onward.