Non-human identity for AI agents: delegate it

What breaks when non-human identity for AI agents is a shared service account?

The audit trail stops at the account, and revocation has nothing to aim at. Non-human identity for AI agents usually begins as a service account with a static key. That is the credential an identity program already knows how to issue.

The pattern is familiar. Someone wires an assistant to the CRM. It needs a credential, so it gets the one the nightly sync uses. The scope is wide, because narrowing it meant a week of 403s. Two months later the same key sits in three more places, and the vendor's own log shows every call as one account. You cannot tell which person asked, which client sent the call, or whether anything was written.

This is a general property of static credentials, not an Elaichi-specific observation. A service account suits a script. A script follows a path somebody wrote down, so scoping it and reviewing it quarterly works. That is the logic behind NIST SP 800-207's zero-trust guidance on least-privilege, per-session evaluation. An agent builds its path at request time, from the prompt in front of it. Scoping a static credential to that would mean covering everything the model might ever need. That defeats scoping entirely.

Elaichi's specific implementation of the fix is OAuth 2.0 delegated authorization (RFC 6749) with PKCE (RFC 7636), not a new protocol. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi's MCP endpoint accepts only an OAuth access token issued against a person's grant, sent as a Bearer token in the Authorization header. A grant is the permission one person gives one named AI client on Elaichi's own consent screen. No Elaichi API token, browser session or pasted vendor key authenticates there, and a request without a valid token gets an HTTP 401.

Every call made with that grant's tokens acts as the person who approved it, in the single organization they picked at consent. Permissions are read on each request rather than frozen into the token, so a role change applies before the token expires. If the key-versus-grant decision is still open, OAuth or API keys for AI agents works through it. Personal API keys with AI tools covers the version where the key belongs to an employee.

How does delegated identity compare to other machine-identity models?

"Delegated identity" is one point on a spectrum of non-human identity architectures. None of these are interchangeable, and picking the wrong one for the workload is the actual failure mode, not a missing feature.

The axis that matters for agents is the third column, not the second. The test is whether you can revoke one person's reach without rotating a shared secret that breaks everyone else's integration. Static keys and client-credentials grants both fail that test by design, because neither one encodes a person. Workload identity and SPIFFE solve a different problem well, service-to-service trust, and are not a substitute for this one.

Why do quarterly reviews of machine identities miss agent behavior?

Because a review of what a credential could reach says nothing about what the agent did with it. The agent picks its tools at runtime, from whatever the person asked for.

In Elaichi, connected tools are never listed one by one, however few there are. The model finds a tool with search_tools and runs it with read_tool for a read, or execute_tool for anything else. The reviewable unit is therefore not the credential and not the advertised tool list. It is the call record.

Each connected-tool call that reaches execution writes an audit entry: one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Elaichi keeps 90 days of audit history. For a longer record, export to your own Datadog comes with the Black plan.

That is a different kind of review. Instead of asking what a key is scoped to, you read what ran, as whom, from which client. Which tools AI agents call walks a real log, and what an AI agent audit log must capture is the field-by-field version.

What does delegated identity change about revocation?

It closes the gap between offboarding a person and cutting off the thing that was acting for them.

Removing a member from an organization revokes every live MCP grant they hold there, inside the same operation that deletes the membership. Suspending them does the same, including a suspension that arrives from the identity provider over SCIM. SCIM sets the member inactive rather than deleting them. Grants are re-read on every request, so that person's AI clients fail on their next call rather than when a token expires. Reactivating them does not bring the grants back; they consent again.

The rest of the access model moves at two speeds. A role change, a team change or a restriction change takes effect about two minutes. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

Two limits belong in the same paragraph as the claim. A completed removal ends that person's reach through Elaichi, meaning their grants, their API tokens and their membership. It does not remove or deactivate their accounts in the connected apps, which stay until each app or the identity provider deprovisions them. Connections they owned need a decision. The offboarding preflight lists them. A private connection that a shared toolbox depends on holds the removal until someone transfers or deletes it. Offboarding AI access covers the whole estate, and SCIM and AI agents covers where provisioning stops.

How does one MCP endpoint keep the identity perimeter from splitting?

By making the address identical for everyone and putting the identity in the grant behind the token. Elaichi serves MCP at https://api.elaichi.ai/mcp, the same string for every organization. Which organization, which person and which tools a client reaches comes from the grant, not from the URL.

There is no per-user, per-team, per-toolbox or per-client address, and no MCP server or token for anyone to create by hand. Claude, ChatGPT, Cursor and Microsoft Copilot all sign into that one address over OAuth. That follows the authorization server model the MCP specification defines. Each person still connects their client once and approves their own grant, and lists or disconnects it under Settings, then Connected apps. Issuing a separate key per client would scatter the record across as many logs as there are clients. One address keeps it in one place.

The client-side half stays in the client's own admin console. These vendor policies are controlled by the client, not by Elaichi. Treat the following as a snapshot, not a permanent fact, and verify against the vendor's own docs before relying on it. On Claude Team and Enterprise plans, an Owner or Primary Owner adds a custom connector from Organization settings > Connectors (checked October 2026, support.claude.com). OpenAI says custom MCP server connections are available for ChatGPT Business and Enterprise/Edu customers on ChatGPT web (checked October 2026, help.openai.com). Cursor supports OAuth for MCP servers that require it (checked October 2026, cursor.com).

One detail to hand your reviewers. A name or logo on a consent screen proves nothing about an app. This is a general OAuth consent-phishing risk, not unique to MCP. Elaichi marks a client's name verified only when every non-loopback redirect address it registered belongs to one of seven known clients. Otherwise the entry shows the name the client registered for itself, flagged as self-reported, and that flag follows into the audit log.

Do vendor-run MCP servers fall under the same rules?

They do, as long as the calls go through Elaichi. The catalog holds 650+ connectors of two kinds. Elaichi authors and runs most of them itself. The rest are native MCP connectors: the vendor builds and runs its own MCP server. Elaichi handles sign-in, access and audit in front of it.

The rules do not fork between the two kinds. Restrictions and OAuth scopes are checked before a call leaves Elaichi. Only a tool on that connection's own active list can run. Every call that runs is written to the audit log, with the person, the connector, the connection and the MCP client. An organization on Gold or Black can also bring its own remote MCP server in as a connector. An Org Owner or Org Admin creates it, and it lands under the same rules.

Calls a client makes to a vendor's MCP server directly, outside Elaichi, do not pass through Elaichi and are not governed by it. That is a structural limit of any gateway pattern, not a gap specific to this one. A reverse proxy only governs traffic it sits in front of. Vendor MCP servers has the longer version.

Where delegated identity is the wrong answer

Some workloads have no person behind them, and no architecture invents one. This is true of any per-person delegated-grant model, not just Elaichi's. If the workload has no human initiator, OAuth's authorization-code grant is the wrong tool. Client-credentials or a workload-identity pattern is the right one.

Elaichi's MCP sign-in supports only the authorization-code grant with PKCE, plus refresh. There is no device-code grant (RFC 8628) and no client-credentials grant (RFC 6749, section 4.4). A new grant always needs a person to approve the consent screen in a browser signed in to Elaichi. A nightly job with no human owner does not get a grant here. It keeps whatever machine identity your platform already issues: a service account, a workload identity, or a SPIFFE SVID. You govern it the way you govern the rest of them.

Three more things a reviewer should hear before deciding.

• Over MCP there is no per-call approval. The grant is the approval: the scopes the person ticked and the toolboxes they chose. For an unattended client, the controls that bind are the ones set in advance. Each is checked on every call: the grant's scopes, its toolbox choice, the caller's restrictions, and frozen arguments on toolbox entries.
• Access tokens are bearer tokens, per the OAuth 2.0 bearer token spec (RFC 6750). Elaichi does not bind them to a device or a sender (no DPoP/mTLS sender-constraining). An access token lasts an hour and a refresh token thirty days. Every refresh rotates, and presenting a used refresh token revokes the whole grant. That is a reuse-detection pattern, not a guarantee against a token stolen and used before rotation.
• Elaichi's MCP endpoint has no prompt-injection defense of its own. It receives a tool name and arguments, never the person's prompt, so it has nothing to judge a call against. That defense belongs to the client. It remains an open problem across the MCP ecosystem, not one this architecture claims to solve.

If the company has one assistant, two apps and three people, none of this is urgent yet. When you don't need an MCP gateway argues that case honestly.

What to do first

Four steps, in this order, and none of them needs a new machine identity.

Give each person one role. A member holds exactly one role in an organization, so each role is a complete persona. To combine two, author a custom role that carries both sets of permissions. Designing roles for AI agents covers the shape.

Write the first restriction on a role, not on the company. A restriction targets a role or one member, and there is no organization-wide or team target. A member is governed by two layers at once, their role's rules and rules aimed at them personally. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. One trap to avoid on day one: an allow rule that names nothing blocks every connector and tool for its target. The two-decision split is set out in role-based access control and audit logs for MCP.

Have each person connect their own client once and approve their own grant, narrowing it to chosen toolboxes where that fits the job.

Then read the log. Connected-tool calls sit in the audit log's assistant category, because that is the action they are written under. The mcp category holds grant events, such as a client being connected. Filter for both in the first month. A security reviewer may ask the same questions in a questionnaire. The seven-question checklist for approving an MCP server is the version they will recognize.

For the wider picture, MCP governance is the pillar this sits under. AI agents with employee permissions is the adjacent argument about shared bots. The governance use case shows where it lands in the product.