KI-Agenten laufen oft als übermächtige 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.

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 Enter fullscreen mode Exit fullscreen mode 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 left side (identity) and the right side (the work) both have owners. The middle question has no owner. That's the gap.

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.

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:

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.

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.