Your AI agents are running as god-mode service accounts

Your support copilot just updated a customer record. Your ops agent just restarted a service. Your coding agent just opened a pull request.

Now answer the one question your auditor — or your incident review, or your own 2 a.m. self — is going to ask:

Who authorized that? Which human, acting through which agent, with whose permissions?

If you're like most teams shipping agents right now, you can't answer cleanly. Not because you were careless — because the tools you wired together were never designed to answer it.

Three ways we wire agent access today — and why each one fails the question

When an agent needs to do something in a real system, its credentials get set up one of three ways. I've done all three. They all leave the same hole.

1. A shared service account. One bot identity behind every agent action. Simple, and it works — until you look at the log:

2026-10-13T09:14:22Z  action=record.update  actor=svc-agent-bot  resource=crm/contacts/8812
2026-10-13T09:14:48Z  action=service.restart actor=svc-agent-bot  resource=prod/api-gateway
2026-10-13T09:15:03Z  action=pr.create       actor=svc-agent-bot  resource=repo/payments

Every line says svc-agent-bot. You've traded per-human accountability for a single god-mode key that half your org can trigger. When something goes wrong, the trail stops at the robot.

2. A credential per agent. Better isolation — now a rogue agent can't do everything. But you've also just created N long-lived secrets to store, rotate, and pray never leak; the agent process holds the raw credential; and the action is still attributed to the agent, not to the human who asked for it. "The invoicing-agent did it" is not an answer to "who authorized it."

3. "We use our IdP." You give the agent an identity in Okta or Entra. This is the right instinct — and it's where most "agent identity" stories stop. But issuing an identity is not the same as governing what the agent does with it. Your IdP hands the agent a token and steps out of the way. It does not sit in the path of the tool call or the shell command and refuse one. And it does not produce an independent record of what the agent did with that token, on whose behalf, and what it was denied.

The hole, drawn

The left side (identity) and the right side (the work) both have owners. The middle question has no owner. That's the gap.

Why the obvious candidates don't fill it

The agent platforms won't. LangChain, Langflow, n8n, and friends exist to help you build and run agents. Governance shows up as a bolt-on feature, and — reasonably — they're not in the business of being a neutral producer of evidence about their own runs. Asking the thing that runs the agent to be the impartial record of what the agent did is a conflict of interest, not an architecture.

The IdPs can't. Identity issuance is genuinely hard and genuinely valuable, and the IdPs are good at it. But they live at the edge — they mint the token and go home. They are not in your tool calls or your exec commands at runtime, so they can't refuse one, and they can't record the thing that matters: the action, not just the login.

So the question falls between two well-funded stools. Which is exactly why, if you've shipped an agent that touches anything real, you've felt the hole even if you couldn't name it.

What "answering the question" would actually require

Forget products for a second. If you were going to design this honestly, the layer that owns the middle would need four properties — none of them exotic:

• Three identities on every action, not one: who asked (the human), what ran (the agent), and whose key acted (the resource) — delegated, so the human is on the wire, not a shared bot.
• The agent never holds the raw credential. It asks; something trusted brokers a short-lived, scoped token; the secret never enters the agent's process.
• Refusal happens in the call path, by construction — not as an after-the-fact alert, and not as a promise the agent will behave.
• Every action and every refusal lands in a tamper-evident record your GRC team can actually read — one that doesn't depend on trusting the agent platform or any single IdP.

Notice what's not on that list: a shiny chat UI, a drag-and-drop builder, an LLM deciding what's allowed. The hard, unglamorous part is the evidence and the enforcement — the boring governance middle that nobody's incentivized to own.

This is a real, unsolved gap

Not a hypothetical. Agents are already acting in production systems with shared keys and no per-human trail, and the two layers best positioned to fix it each have a structural reason not to. That's usually where a new, narrow layer belongs.

That gap is what I'm building an open-source layer for — Agenthof, Apache-2.0, a governance plane that sits beside your IdP and your agent framework rather than replacing either. It's early and I'm honest about its limits. In the next post I'll show the thing working: an agent acting as me in a real system, unable to exceed its grant, with the audit trail that proves it. If the question at the top of this post made you wince, the repo's here — a star helps me find the people who feel this.