Agent Identity: How Mittelstand IT Teams Govern Authentication and Access for AI Agents

The first AI agent at a Mittelstand firm usually logs in with the same service account someone created in 2017 for a nightly DATEV export. The second agent logs in with the same one. By the third, half the IT department uses it. Six months in, an external auditor asks who actually changed the supplier master record on a Tuesday at 02:14 - and nobody can tell whether it was a human, an agent, or both at once.

That is the moment most Mittelstand teams discover they do not have agent identity. They have shared accounts, ungoverned secrets, and an audit trail that collapses the moment anyone looks at it. According to GitGuardian’s 2026 report, 28.6 million new secrets were exposed in public GitHub commits across 2025 alone, with AI-assisted code leaking at roughly double the baseline rate¹. Independent surveys put 88 percent of enterprises at having already had an AI-agent security incident⁴. The pattern is consistent: the technology shipped faster than the identity governance.

This guide covers what agent identity actually is, the three authentication flows you need (workload-to-workload, on-behalf-of-user, agent-to-agent), the SPIFFE plus OAuth 2.1 plus MCP stack that has settled in 2026, the seven pitfalls that derail Mittelstand projects, and a 90-day roadmap to get from shared service account to first-class agent identity. Written for IT leaders, platform engineers, and the Geschäftsführer who has to sign off when something goes wrong.

Why Agent Identity Matters Now

Six concrete reasons agent identity has gone from a future problem to a 2026 deliverable.

• Agents are everywhere already - Industry reports forecast 30 percent of enterprises will rely on AI agents that act independently by year-end 2026, triggering transactions and completing tasks on behalf of humans or systems¹. The agents are deployed; the identity governance is what is missing.
• The non-human identity ratio has exploded - Machine identities outnumber human identities 25 to 50 times in modern enterprises, with the ratio accelerating as agent deployment scales¹. The Mittelstand IT team that governed 200 employees now governs 5,000 to 10,000 non-human identities.
• Secrets are leaking at industrial scale - GitGuardian found 28.6 million new secrets exposed in public GitHub commits across 2025, a 34 percent year-on-year jump and the largest in the report’s history. AI-assisted code leaks secrets at roughly double the GitHub-wide baseline¹.
• 88 percent of enterprises had an incident in 2026 - Industry surveys find 82 percent of executives confident their policies prevent unauthorised agent action, while 88 percent of organisations have already had incidents those policies failed to prevent⁴. The confidence gap is the gap.
• Supply chain attacks now include agent platforms - On 19 April 2026, Vercel disclosed it was breached via Context AI, which had itself been compromised⁶. Agent platforms have third-party dependencies that become identity-attack surface.
• Least privilege is the largest available risk reduction - Organisations enforcing least-privilege access for AI agents report a 17 percent incident rate, versus 76 percent for those that do not⁴. No other single control comes close.

The Shared-Account Trap (and How Mittelstand Teams Fall Into It)

The pattern that creates 90 percent of Mittelstand identity incidents is not malicious - it is convenience accumulated over months. Five steps that take a Mittelstand IT team from clean to compromised, every one of them well-meant.

1. Step 1 - The first agent ships - The team needs an agent to read SAP. They use the existing nightly-export service account because creating new accounts requires Compliance approval and they want to ship this week.
2. Step 2 - The second agent reuses the account - A different team builds an HR agent and asks IT for SAP read access. IT gives them the same service account because the permissions are already there.
3. Step 3 - Permissions accumulate - Each new agent needs slightly different access. The service account is granted more permissions to satisfy them all. By month four, the service account has more privileges than any human in the company.
4. Step 4 - The audit trail collapses - When something happens, the log shows the service-account name. Nobody can tell which agent did what. Forensics becomes guesswork.
5. Step 5 - The kill switch fails - A security incident requires revoking one agent. Revoking the service account breaks every other agent. The team chooses to live with the incident rather than break production.

Why the trap is hard to avoid by accident

• Service accounts feel right - They have worked since the 1990s. Most Mittelstand IT teams do not have a mental model for “identity per agent” because there was never a need.
• Compliance friction is real - Creating a new identity goes through approval, naming convention, ownership assignment, periodic recertification. Reusing an existing one is two clicks.
• Tooling is split - Microsoft Entra, AWS IAM, SAP authorisations, DATEV permissions, custom APIs - each has its own model. Without a non-human identity layer, “one identity per agent” means N copies of identity work per agent.
• Nobody owned the question - Identity belonged to IT, agents belonged to a business team, security belonged to InfoSec. Agent identity sat in the seam and never got an owner.

What Agent Identity Actually Is

Strip away the vendor language and agent identity has a simple definition. It is the cryptographic and organisational record that uniquely identifies one AI agent across every system it touches, distinct from any human, distinct from any other agent, with five mandatory attributes.

• Unique identifier - A cryptographically verifiable name (SPIFFE ID, X.509 certificate, OIDC subject) that no other identity in the system shares. Generic names like “ai-agent-1” are not enough; the ID must be traceable to a specific agent definition and version.
• Named owner - A specific human (or rotating role) responsible for the agent. When the owner leaves the company, the agent is flagged in the same way a departed employee triggers an account review³.
• Scoped permissions - The minimum access required to do the job, expressed as resource scopes, not roles. Roles accumulate; scoped permissions are atomic and can be revoked individually.
• Bounded lifetime - Tokens that auto-rotate (minutes to hours, not months), with a clear total lifespan for the agent itself. No agent runs forever; it is renewed or retired.
• Audit trail - Every action attributable to this specific agent identity, with the human (if any) on whose behalf it acted, and the context that justified it. Aggregated logs that say “ai-agent-1 did X” are not enough.

The Three Authentication Flows Every Agent Stack Needs

The 2026 consensus, reflected in MCP, A2A, and the major non-human identity platforms, splits agent authentication into three flows. Each one solves a different problem and uses a different pattern. Conflating them is the second-most-common Mittelstand mistake after the shared-account trap.

Flow 1: Workload-to-workload (the agent proves it is itself)

• What it is - One service or agent identifies itself to another service inside your infrastructure. No human is in the loop. The receiver wants cryptographic proof that the caller really is who it claims.
• Standard pattern - SPIFFE ID and SVID issued by SPIRE. Each agent gets a unique identifier and a short-lived X.509 or JWT credential, automatically rotated¹⁵.
• Where it fits - Agent calling internal microservices, agent reading from internal databases, agent invoking other agents inside your VPC.
• What replaces what - Long-lived API keys and shared service accounts. SPIFFE removes the need for either.

Flow 2: On-behalf-of-user (the agent acts as a specific human)

• What it is - The agent acts using the authority of a specific human user. The receiving system needs to know both that the agent is legitimate AND who the human is.
• Standard pattern - OAuth 2.1 with the on-behalf-of flow (RFC 8693 Token Exchange). The agent presents its own identity plus a delegated user token; the resource server verifies both.
• Where it fits - Agent reading a customer email on behalf of an account manager, agent writing to a CRM record on behalf of a sales rep, agent processing an HR record on behalf of an HR business partner.
• What replaces what - Agents that “just have access” to user data. On-behalf-of preserves the audit trail and ensures actions are attributable to the right human.

Flow 3: Agent-to-agent and agent-to-MCP-server

• What it is - One agent calls another agent (often across organisational boundaries) or calls an MCP server to use a tool. The standard explicitly mentions cross-trust-boundary scenarios.
• Standard pattern - MCP authorization based on OAuth 2.1 with PKCE and RFC 8707 Resource Indicators²⁰. For pure agent-to-agent, Google A2A and Anthropic agent communication add their own layers.
• Where it fits - Agent calling an MCP server for SAP, DATEV, SharePoint, or external tools. Agent participating in a multi-agent workflow. Agent receiving requests from a customer’s buying agent.
• What replaces what - Pre-shared API tokens, vendor-specific authentication schemes, and bespoke per-tool wiring.

SPIFFE, OAuth 2.1, and MCP: The 2026 Stack

The three standards have settled into specific layers that compose well. None of them is novel; the combination is what is new.

SPIFFE and SPIRE for workload identity

• What it is - SPIFFE (Secure Production Identity Framework for Everyone) is the standard, SPIRE is the reference implementation. Each workload gets a SPIFFE ID like spiffe://yourcompany.de/agents/customer-service/v3 and a short-lived cryptographic credential (SVID) that proves it¹⁵.
• Why it matters for agents - SPIFFE IDs are tied to workloads, not people, making them ideal for AI agents and other non-human entities. Each agent gets a unique cryptographic identity that proves origin, capabilities, and trust level¹⁷.
• Mittelstand pattern - Run a SPIRE server (managed or self-hosted) inside your environment, issue SPIFFE IDs to every agent and tool, federate with cloud and SaaS where supported.

OAuth 2.1 with PKCE and Resource Indicators

• What it is - OAuth 2.1 consolidates the OAuth 2.0 best practices and removes the legacy parts. PKCE (Proof Key for Code Exchange) is mandatory; implicit flow is gone. RFC 8707 Resource Indicators bind a token to a specific resource server, preventing reuse across systems²².
• Why it matters for agents - When an agent has a token meant for SAP, that token cannot be replayed against DATEV. The blast radius of a compromised token is bounded.
• Mittelstand pattern - Every external API, every MCP server, every tool the agent calls: OAuth 2.1 with Resource Indicators, short-lived tokens, refreshed automatically.

MCP authorization for tool access

• What it is - The Model Context Protocol authorization specification, based on OAuth 2.1, governs how an agent calls an MCP server to use a tool²⁰. As of March 2026 MCP has surpassed 97 million monthly SDK downloads and is supported by every major AI vendor.
• Why it matters for agents - MCP is becoming the default surface between agent and tool. If MCP auth is right, the rest of the tool security model gets simpler. If it is wrong, the tool surface becomes the new attack surface.
• Mittelstand pattern - Treat every MCP server as an OAuth Resource Server. Use Resource Indicators for every token. Propagate user identity through the agent so the audit trail terminates at a human, not at “the agent”.

A Reference Architecture for Mittelstand Agent IAM

The components that have settled into place for production-grade agent identity in 2026. None are novel; the value is in choosing the right combination for a Mittelstand context and wiring them sensibly.

1. Identity provider for humans - Microsoft Entra ID, Okta, or Keycloak. Already in place at most Mittelstand firms. Stays as the source of truth for human identity and the federation root for on-behalf-of flows.
2. Workload identity layer - SPIRE server (managed by HashiCorp, Tetrate, or self-hosted) issuing SPIFFE IDs and SVIDs to every agent and tool. The cryptographic substrate everything else builds on.
3. Non-human identity platform - Astrix, Entro, Oasis, or comparable. Inventory, ownership, lifecycle, kill switch. The pane of glass that lets a single human govern thousands of agents.
4. Secrets manager - HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or 1Password Business. Never put credentials in prompts or code; inject at runtime through the secrets manager.
5. OAuth 2.1 authorisation server - Auth0, Keycloak, Microsoft Entra, or self-hosted. Token issuance with PKCE and Resource Indicators for every external API call.
6. MCP server registry - The list of every MCP server your agents may call, with the OAuth scopes each one requires. Reviewed quarterly with security.
7. Agent activity observability - Every action by every agent identity logged to a SIEM (Splunk, Elastic, Sentinel) with the SPIFFE ID, on-behalf-of user, target resource, and outcome.
8. Kill-switch service - The single API that flips an agent identity to suspended, propagates the change to every downstream system within seconds, and produces an audit record.

Least-Privilege Authorization in Practice

Least privilege is the largest measurable risk-reduction control available in agentic AI - 17 percent incident rate with it, 76 percent without⁴. Six concrete patterns that translate the principle into a Mittelstand operating model.

• Resource scope, not role - Grant agents access to specific resources (this customer record, this cost centre, this date range), not to broad roles (sales, finance, HR). Resource scopes are atomic; roles accumulate.
• Just-in-time provisioning - The agent receives the permissions it needs the moment it needs them, for as long as it needs them. Token TTLs in minutes, not weeks. Industry guidance is consistent: short-lived, JIT, narrowly scoped¹.
• Read-only by default - Every new agent ships read-only. Write capability is granted explicitly, per resource type, with an explicit rollback path. Most pilots never need write access; the ones that do should justify it.
• Per-environment tokens - Sandbox, staging, and production each have their own token issuer. A token that escapes sandbox cannot touch production. RFC 8707 Resource Indicators make this enforceable cryptographically.
• Behavioural ceilings - Rate limits per agent identity, per minute and per day. An agent that suddenly tries to read 10,000 customer records gets blocked, not approved. The ceiling is the safety net beneath least privilege.
• Quarterly recertification - Every agent identity reviewed every quarter: still needed, still scoped correctly, owner still in place. Anything that has not been used in 30 days is suspended; anything suspended for 90 days is deleted.

Identity Lifecycle and the Kill Switch

An agent identity has six lifecycle states. Designing for the unhappy paths matters more than designing for the happy one - because the unhappy paths are when audit, compliance, and security break.

1. Requested - A team requests a new agent identity. Owner named, scope drafted, business case attached. Compliance review attaches.
2. Provisioned - SPIFFE ID issued, OAuth client registered, secrets created, scopes attached. The agent can now run.
3. Active - Agent is in production. Tokens auto-rotate, activity is logged, behaviour is monitored against baseline.
4. Recertified - Quarterly review confirms the agent is still needed, still scoped correctly, still owned. Anything failing recertification moves to suspended.
5. Suspended - Identity remains in the system but every authorisation check returns denied within seconds. The kill switch state. Reversible.
6. Retired - Identity removed. Tokens revoked. Audit logs preserved per retention policy. SPIFFE ID never reused.

The kill drill

The kill switch only matters if it works. Three practices that distinguish drills from theatre.

• Quarterly fire drill - Pick one production agent at random, suspend it via the IAM platform, time how long until every downstream system denies it. Target: under 60 seconds. If it takes longer, fix it before the real incident.
• Single source of truth - One platform owns the suspended state. SAP, DATEV, MCP servers, custom APIs - all subscribe to it. No system has its own independent allow list that could survive a kill.
• Stress test the propagation - The IAM platform itself must propagate the suspended state without a human in the loop. If a human has to call SAP basis to revoke an agent, you do not have a kill switch; you have a help-desk ticket.

The 7 Identity Pitfalls That Derail Mittelstand Projects

The pattern of failure is consistent enough to enumerate. Each is preventable; almost all happen in the first six months of agent rollout.

1. Agents share a service account - The original sin. Audit collapses, kill switch becomes nuclear option, accumulating permissions. Fix: one identity per agent from the first deployment. The friction is real but the alternative is worse.
2. Long-lived secrets in code or prompts - API keys hardcoded in agent definitions, secrets pasted into prompts to debug, credentials in screenshots. GitGuardian found 28.6 million such leaks in 2025¹. Fix: secrets manager + scanning + rotation on detection, not after.
3. No kill switch, or one that does not work - The IAM platform suspends the agent but SAP keeps accepting its old token because the token has not expired. Fix: short-lived tokens (minutes), revocation propagation, quarterly drill.
4. Identity propagation forgotten - The agent calls an MCP server, the MCP server logs only the agent identity, not the user the agent acted for. The audit trail terminates at “the agent”. Fix: propagate user identity end-to-end, log it everywhere.
5. Permissions granted, never revoked - Each agent accumulates permissions over time. Nobody cleans up. After a year the agent has more access than the CFO. Fix: quarterly recertification, automatic expiry of unused permissions.
6. Third-party dependencies ungoverned - Memory provider, observability provider, embedding provider - each holds an identity for your agent. The Vercel-Context AI breach in April 2026 is the canonical example⁶. Fix: identity per provider, separate kill switch per provider, supply-chain diligence.
7. No owner - The agent was built by a team that has since dissolved. Nobody knows what scope it needs or whether it should still exist. Fix: every agent identity has a named human or rotating role; agents without an owner are auto-suspended.

EU AI Act, GDPR, and ISO 27001

Agent identity sits at the intersection of three German Mittelstand compliance regimes. None of them mention “agent identity” explicitly; all of them require it implicitly.

EU AI Act

• Article 4 (AI literacy) - Adequate AI literacy for everyone using or directing AI tools²⁶. Includes the platform team that runs the IAM and the security team that runs the kill drill.
• Article 14 (human oversight) - Designed-in human oversight for high-risk systems²⁷. Agent identity is the technical substrate that lets oversight actually intervene - without it, “suspend the agent” is impossible.
• Mittelstand action - Map every agent identity to a specific oversight contact. The contact is the human Article 14 names when it asks who supervises this AI.

GDPR

• Auftragsverarbeitung (Article 28) - Each third-party identity provider, MCP server provider, and observability provider needs a signed DPA. Keep the list short; review annually.
• Right of access and erasure (Articles 15 and 17) - Identity propagation through the agent stack is what makes “every action attributable to a specific user” technically possible. Without it, fulfilling access and erasure requests becomes guesswork.
• Mittelstand action - Identity propagation as a hard architectural requirement. The audit trail must terminate at a human, not at “the agent”.

ISO 27001 and BSI C5

• A.9 Access Control - ISO 27001:2022 control 5.15 to 5.18 cover identity management, access rights, and management of privileged access. Non-human identities sit squarely inside scope²⁹.
• BSI C5 - The German cloud-computing compliance catalogue requires authentication and authorisation controls that apply equally to non-human identities²⁸.
• Mittelstand action - Add agent identity to the ISO 27001 statement of applicability. Document the kill drill as a control test.

Betriebsrat

• Why it matters - On-behalf-of flows mean an agent acts using a specific employee’s authority. The works council has a legitimate interest in the policy that governs this.
• Mittelstand action - One-page policy describing what agents may do on behalf of which employees, signed off once, applied to every agent.

A 90-Day Implementation Roadmap

The work breaks into three 30-day sprints. By day 90 a Mittelstand team has every production agent on a unique identity, with a working kill switch and a documented audit story.

Days 0-30: Inventory and the first identity

• Inventory every agent and shared account - List every AI agent, MCP server, and shared service account currently in use. Most teams find 3 to 10 times more than they expected.
• Pick the IAM platform - Astrix, Entro, Oasis, or self-hosted SPIRE plus secrets manager. Decision in week one, integration in weeks two and three.
• Stand up the secrets manager - HashiCorp Vault if you do not already have one. Move the first 5 secrets out of code and prompts.
• Issue the first agent identity - One pilot agent gets its own SPIFFE ID, scoped permissions, named owner, short-lived token. Document the process.
• Set the policy - One-page document covering naming, ownership, scope, lifetime, kill switch. Reviewed by Compliance and the Betriebsrat.

Days 31-60: Migrate, propagate, drill

• Migrate every existing agent - One identity per agent. Retire the shared service accounts as agents move off them.
• Wire identity propagation - Through every MCP server, every internal API, every external tool. The audit trail must terminate at a user, not at the agent.
• Run the first kill drill - Suspend a non-critical agent, time the propagation. Fix anything that takes longer than 60 seconds.
• Centralise the audit log - Every agent action in one SIEM with SPIFFE ID, on-behalf-of user, resource, outcome.
• Train the platform team - Article 4 module covering NHI, OAuth 2.1, SPIFFE, MCP authorisation, and the kill drill itself.

Days 61-90: Hardening, recertification, second wave

• Stress-test third-party providers - For each memory, observability, and embedding provider: separate identity, separate kill switch, supply-chain diligence.
• Enable least privilege everywhere - Audit every agent identity for over-broad scopes. Reduce until each does only what it needs.
• Quarterly recertification process - Documented, owners assigned, automatic expiry of unused permissions.
• Add the next 5 agents - Now on the identity rails by default. New agents inherit the framework instead of inventing their own.
• Document the audit story - One-page diagram covering identity flow, kill switch, recertification, supply chain. The artefact you hand the auditor.

How Superkind Fits Into Agent Identity

Superkind builds custom AI agents for the Mittelstand with identity treated as a first-class part of the architecture rather than something added later. We typically own the SPIFFE rollout, the OAuth and MCP wiring, the kill-switch drill, and the audit story for the agents we ship.

• One identity per agent from day one - SPIFFE ID, named owner, scoped permissions, short-lived tokens. No shared service accounts, no exceptions.
• OAuth 2.1 plus MCP authorisation wiring - Every external tool call resource-bound, every user action propagated, every token short-lived.
• Secrets manager integration - HashiCorp Vault or the manager you already use. Credentials never appear in prompts, code, or screenshots.
• Kill-switch design and drill - One API, propagation under 60 seconds, quarterly drill as a service we run with your team for the first year.
• Identity propagation through the agent stack - SAP, DATEV, SharePoint, custom APIs - the audit trail terminates at a human, not at the agent.
• Third-party provider governance - Separate identity per memory, observability, and embedding provider. Supply-chain diligence as a permanent practice, not a one-time check.
• EU AI Act and GDPR alignment - Article 4 literacy, Article 14 oversight, Article 28 DPA paperwork covered as part of the engagement.
• ISO 27001 and BSI C5 mapping - Identity controls mapped to your existing certification scope.

Decision Framework: Is Our Agent Identity Ready?

A six-dimension check that helps a Mittelstand IT lead and Geschäftsführer answer the readiness question in one steering session.

Most Mittelstand firms in 2026 land in the “not ready” column on three or more dimensions. The right answer is not to wait. The right answer is to fix the not-ready columns as the first 90 days of agent IAM, not as preconditions to deploying any agent at all.

Frequently Asked Questions

Related Articles

• AI Agent Security: Prompt Injection, Data Leakage, and the OWASP LLM Top 10
• Persistent Context for AI Agents: What Mittelstand IT Teams Need to Know About Memory Design
• Software 3.0 in the Mittelstand: Why Programming Is Now Prompting
• Human-in-the-Loop: Building Trust in AI Agents
• Sovereign AI for the Mittelstand: Why EU Data Residency Becomes a Competitive Advantage
• EU AI Act 2026: What the Mittelstand Must Know Before August
• Shadow AI in the Mittelstand: The Governance Playbook
• SAP and AI Agents: The Pragmatic Path Through S/4HANA, ECC, and Business One

Henri Jung

Co-founder of Superkind, where he helps SMEs and enterprises deploy custom AI agents that actually fit how their teams work. Henri is passionate about closing the gap between what AI can do and the value it creates in real companies. He believes the Mittelstand has everything it needs to lead in AI - it just needs the right approach.