DEV Community: Akash Devdhar

Designing Multi-Tenant Identity Systems

Akash Devdhar — Wed, 09 Sep 2026 17:52:07 +0000

Most multi-tenant applications are one missing filter away from becoming somebody else's data breach. That sounds dramatic, but the architecture is often exactly this: accept a tenant_id from the request, add it to a SQL query, and call the system isolated. It is not isolated. It is trusting the caller to tell you which security boundary should apply, which is basically asking the request to authorize itself.

A tenant is not just a row partition. It is an identity and authorization boundary, full stop. If that boundary is not established from a verified identity and enforced at every layer that touches protected data, then the application is multi-tenant only in the product brochure.

The dangerous version looks reasonable

The most common design is attractive because it is simple. A frontend knows the current tenant, so it sends X-Tenant-ID. The API reads the header and uses it in every repository query. Engineers review the query and see WHERE tenant_id = ?, so everybody feels safe.

The issue is not the filter. The issue is who supplied its value.

app.get("/invoices", async (req, res) => {
  const tenantId = req.header("X-Tenant-ID");

  const invoices = await db.invoice.findMany({
    where: { tenantId },
  });

  res.json(invoices);
});

An authenticated user can change a header only. If the API does not independently prove that the user belongs to that tenant, the filter is doing exactly what the attacker requested. Authentication succeeded, the database query is scoped, and the data is still wrong. This is why authentication and tenant isolation cannot be separate conversations.

What I am noticing is that teams are putting tenant selection inside application state, when it belongs inside verified security context. The browser can request a tenant switch, of course, but the identity layer must decide whether that switch is permitted and mint or establish the resulting context. The browser does not get to declare it as fact.

Derive tenant context from identity

The safer model begins with a verified session or access token. That identity carries a subject, an audience, and either a tenant claim or enough membership information for the authorization service to resolve one. The API validates the token, confirms membership, then creates an internal request context that downstream code cannot replace with a header or request-body field.

type TenantContext = {
  subjectId: string;
  tenantId: string;
  scopes: Set<string>;
};

async function buildTenantContext(req: Request): Promise<TenantContext> {
  const token = await verifyAccessToken(req.headers.authorization);
  const requestedTenant = req.headers["x-tenant-id"];

  if (typeof requestedTenant !== "string") {
    throw new Error("tenant context is required");
  }

  const membership = await memberships.findActive(
    token.subject,
    requestedTenant,
  );

  if (!membership) {
    throw new Error("subject is not a member of this tenant");
  }

  return {
    subjectId: token.subject,
    tenantId: membership.tenantId,
    scopes: new Set(token.scopes),
  };
}

The header still exists here, but it is a request to select from the user's verified memberships, not proof of membership by itself. That difference is the whole model actually.

For an AI agent, the context needs one more piece: delegation. The agent's own identity tells you which workload is calling. It does not automatically prove which customer or human authorized this task. A useful agent token or token-exchange result should preserve both the agent identity and the delegated subject, with a narrow tenant and audience. Otherwise one agent credential can quietly become a bridge between every customer the service supports.

OAuth 2.0 Token Exchange, defined in RFC 8693, is useful here because a service can exchange an upstream token for a narrower downstream token. The new token can target one resource server and one tenant context rather than forwarding a broad credential through the full service chain. OpenID Connect claims establish identity, but your authorization policy still has to decide how those claims map to tenant membership.

Carry the boundary through every hop

Verifying tenant membership at the first API is necessary, but it is not enough only. Multi-tenant systems usually have queues, background jobs, internal APIs, caches, and agents calling tools. Tenant context gets lost at these boundaries because developers serialize the business payload and forget the security context that made the action valid.

A background job should never wake up with only an invoiceId and then search globally. It should carry the tenant identifier, initiating subject, and authorization purpose, and the worker should verify those values before acting. Internal services should receive a signed, audience-bound token rather than a forwarded browser header. Cache keys must include the tenant boundary also, otherwise perfectly authorized reads can leak through a shared cache.

The important part in this design is that each service treats tenant context as security input. It is not ordinary metadata that can be dropped, overwritten, or filled with a default when missing. Missing tenant context should fail closed.

Enforce isolation again at the data layer

Application checks are valuable, but relying on every engineer to remember every filter forever is a weak last line of defense. The repository or database layer should make cross-tenant access difficult by construction.

PostgreSQL Row-Level Security is one option. The application sets verified tenant context on the database session, and a policy restricts rows regardless of which query the application writes.

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
USING (tenant_id = current_setting('app.tenant_id')::uuid)
WITH CHECK (tenant_id = current_setting('app.tenant_id')::uuid);

This is not magic. Connection pooling has to reset session state correctly, privileged database roles must not bypass the policy casually, and migrations need testing. But it changes the failure mode. A forgotten application filter becomes a denied query instead of a customer-data incident.

Some systems choose separate schemas or separate databases for stronger isolation. That can be the correct decision for regulatory or high-value tenants, but it adds operational cost. The point is not that one storage model wins everywhere. The point is that the isolation strength should match the consequence of crossing the boundary, and it should not depend on a single controller remembering a WHERE clause.

Tenant membership is lifecycle data

Identity architecture tends to focus on login, while tenant membership keeps changing after login. Users join organizations, leave them, switch roles, and sometimes belong to several tenants at once. Agents get reassigned or disabled. A token issued yesterday can carry authorization that is no longer true today.

Keep access tokens short-lived. Re-evaluate membership when selecting a tenant or performing sensitive work. Use SCIM where it fits for enterprise provisioning and deprovisioning, but do not assume that provisioning alone gives you runtime authorization. SCIM can tell your system that a user was removed. Your session and token design determines how quickly that removal actually stops access.

Audit records should capture at least the effective tenant, the human or workload subject, delegated identity when present, the action, and the authorization decision. Logging only user_id is not enough in a system where the same subject can act inside multiple customer boundaries.

The takeaway

The tenant boundary must come from identity, travel with the request, and be enforced where the data lives. If any layer can guess it, default it, or accept it without verification, then that layer can cross it also.

A tenant_id column is useful data modeling. A verified tenant context is security architecture. Multi-tenant systems need both, and confusing one for the other is how an application ends up showing the right query in code review and the wrong customer's data in production.

Akash Devdhar is a Senior Software Engineer specializing in enterprise identity, authentication, authorization, and AI infrastructure. He writes about building secure AI systems using OAuth, OIDC, RBAC, and modern identity architectures.

RBAC vs ABAC: Choosing the Right Authorization Model

Akash Devdhar — Wed, 02 Sep 2026 17:56:32 +0000

Every time an AI agent project hits its first "wait, this agent should not have been able to do that" moment, someone proposes the same fix: add more roles. Split "support_engineer" into "support_engineer_tier1" and "support_engineer_tier2." Add a "read_only_agent" role. This works for about two more incidents, and then you have forty roles, half of them overlapping, and nobody actually knows what any of them mean anymore. That is the point where the conversation should shift from RBAC to ABAC, and it is also the point where most teams do it wrong, because they treat ABAC as "RBAC but with more config" instead of an actually different way of thinking about the problem.

What RBAC is actually good at, and where it stops working

Role Based Access Control is simple, and simple is a feature, not a weakness. You define a role, "support_engineer," you attach a fixed bundle of permissions to it, "read tickets, read customer profile," and you assign the role to a subject, human or agent. This works great when permissions genuinely cluster into a small number of stable job functions. It is also exactly why it breaks for agents.

An agent's required permissions are not a fixed job function, they are a function of context. The same support agent should be able to read a ticket in its own team's queue but not in a different team's queue. It should be able to act during business hours on a live incident but maybe not at 3am unattended. It should be able to act on behalf of the specific user who invoked it, not on behalf of any user who happens to share its role. RBAC has no native concept of "in its own team's queue" or "on behalf of this specific user," so people fake it with more and more roles, and the role explosion is the actual symptom, not the disease.

What ABAC actually changes

Attribute Based Access Control does not ask "what role does this subject have." It asks "given everything we know about the subject, the resource, and the environment right now, does this specific action pass the policy." Subject attributes: which team, which clearance level, who delegated to it. Resource attributes: which team owns this ticket, how sensitive is it. Environment attributes: what time is it, is this an emergency escalation. The decision is computed at request time, not looked up from a static table.

This is genuinely more powerful for the "agent acting on behalf of a specific person, in a specific context" problem that RBAC struggles with. It is also more work, and this is the part people skip. ABAC without a real, maintained policy set is not more secure than RBAC, it is just a different place to hide the same mess, and honestly a worse one, because a bad ABAC policy is harder to audit at a glance than a list of forty overlapping roles.

The honest tradeoff

I am not telling you ABAC is strictly better, that would be dishonest actually. RBAC is easier to reason about, easier to audit ("show me everyone with the admin role" is a one line query), and perfectly fine for systems where permissions genuinely map to stable job functions. ABAC is the right call once your access decisions depend on context that changes per request, which for agent systems is most of the time, but only if someone actually owns writing and testing the policies, the same way someone has to actually own the role definitions in an RBAC system that is not a mess. Neither model saves you from doing the thinking, they just organize where the thinking lives.

A quick code example

RBAC, a straightforward role lookup:

ROLE_PERMISSIONS = {
    "support_engineer": {"tickets:read", "customer_profile:read"},
}

def is_allowed_rbac(subject, action):
    role = subject.role
    return action in ROLE_PERMISSIONS.get(role, set())

ABAC, a policy evaluated against subject, resource, and environment attributes:

def is_allowed_abac(subject, resource, action, env):
    if action == "tickets:read":
        same_team = subject.team == resource.team
        within_hours = env.hour in range(6, 22)
        acting_for_owner = subject.delegated_by == resource.owner_id
        return same_team and (within_hours or acting_for_owner)
    return False

Notice the ABAC version is not longer because ABAC is inherently more complex, it is longer because it is actually encoding the real rule, "same team, and either business hours or acting for the resource's owner," instead of pretending that rule can be flattened into a role name.

Standards worth reading

INCITS 359-2012, the NIST RBAC model, for the formal definition of roles, permissions, and role hierarchies.
NIST SP 800-162, Guide to Attribute Based Access Control, for how to actually define subject, resource, and environment attributes and structure policies around them, this is the one to read before building an ABAC system, not after.

The takeaway

RBAC fails for agents not because roles are a bad idea, but because agent permissions are contextual and roles are not. ABAC fixes that by making the decision live instead of a lookup, but it only works if you put in the same discipline you would have needed for RBAC anyway, just applied to policies instead of role definitions. Pick RBAC when your access model genuinely maps to stable jobs. Pick ABAC when it depends on who, what, and when, and budget the time to actually own the policies, because an unmaintained ABAC system is not a safer RBAC system, it is a harder to audit one.

Building Identity into AI Applications from Day One

Akash Devdhar — Wed, 26 Aug 2026 15:56:01 +0000

Almost every team I am talking to treats identity as a security review item, something you bolt on right before launch once legal and infosec start asking questions. For a normal CRUD app, you can mostly get away with that, badly, but you get away with it. For an AI application, this is backwards in a way that actually costs you real engineering time later, because agent identity is not a checklist item you add at the end, it is wiring that has to run through the whole thing from the first commit.

Why retrofitting identity is so much more expensive here

With a traditional app, bolting on proper authorization later mostly means adding middleware and updating some route handlers. Painful, but contained.

With an AI application, by the time someone notices the identity gap, you usually have: a growing list of tools the agent can call, each one written without a scope in mind because nobody was thinking about scopes when they wrote def send_email(to, subject, body):. A shared service account or a single API key wired into every integration, because that was the fastest way to get a demo working. No per-agent, per-session distinction in your logs, because logging was "add a print statement" not "log against an identity." Retrofitting at that point means touching every tool, reissuing every credential, and rebuilding your audit trail from nothing, all while the thing is already in production and agents are already calling those tools. That is a much bigger job than adding middleware, and it is also exactly the kind of migration that gets deprioritized forever because nothing is technically broken, it is just quietly unsafe.

The four things worth wiring in from day one

Give every agent instance its own identity. Not a shared service account "for now." Even in a prototype, issue a distinct client identity per agent or per deployment. It costs almost nothing at day one and it is the one piece that is genuinely painful to add after the fact, because everything downstream (tokens, scopes, audit logs) hangs off of it.

Map every tool to a scope before you write the tool, not after. When you are defining send_email or run_sql_query, decide right then what scope should gate it. This is a five minute conversation at design time and a multi-week migration once forty tools exist without one.

Design token issuance and expiry into the architecture, not into a later "security hardening" sprint. Short lived, scoped tokens (OAuth 2.0 client credentials or token exchange per RFC 8693) should be how the agent gets access from the start, even if the actual identity provider behind it is a stub in your prototype.

Build the audit trail against identity, not against generic app logs. Every tool call should be attributable to a specific agent identity and the scope it used to make that call. Bolting this on later means you have a gap in your history exactly during the period you probably most need to explain, which is early production, when things are still being figured out.

What happens if you skip this and retrofit later

I am not saying this to be dramatic, I am saying it because I am watching it happen basically every quarter with a different team. The MVP ships fast with one shared key because that is genuinely the right tradeoff for a two week prototype. Then the prototype works, more tools get added, more agents get spun up, all against the same shared credential because changing it now would mean touching working code. Eventually someone asks "which agent did this" during an incident review and the honest answer is "we cannot tell," and now the retrofit is not a nice-to-have, it is an incident follow-up item with a deadline.

A quick code example

Here is roughly what "no scope was designed in" looks like, which is the natural result of moving fast without thinking about identity first:

def send_email(to: str, subject: str, body: str):
    # works fine, called by whichever agent, however often, no scope check
    smtp_client.send(to, subject, body)

And here is what it looks like when the scope is part of the tool's definition from the moment it is written, not added later:

from dataclasses import dataclass

@dataclass
class Tool:
    name: str
    required_scope: str
    handler: callable

def send_email(to: str, subject: str, body: str):
    smtp_client.send(to, subject, body)

TOOL_REGISTRY = {
    "send_email": Tool(
        name="send_email",
        required_scope="email:send",
        handler=send_email,
    ),
}

def call_tool(tool_name: str, token, **kwargs):
    tool = TOOL_REGISTRY[tool_name]
    if tool.required_scope not in token.scopes:
        raise PermissionError(f"token missing scope: {tool.required_scope}")
    return tool.handler(**kwargs)

Nothing complicated about the second version, that is actually the point. It is barely more code. The difference is entirely about when you decided to think about it.

Standards worth reading

RFC 6749, The OAuth 2.0 Authorization Framework, for the base client identity and scope model.
RFC 8693, OAuth 2.0 Token Exchange, for how a per-agent identity gets a narrower, short lived token for a specific downstream call.
NIST SP 800-207, Zero Trust Architecture, for the general principle that identity and verification should be part of the architecture, not a perimeter you add once and trust forever after.

The takeaway

You do not need a fully built out identity provider on day one, a stub is fine for a prototype. What you actually need on day one is the shape: distinct identity per agent, a scope decided before the tool is written, tokens instead of shared secrets, and logs tied to identity instead of generic app output. Fill in the real infrastructure later if you must, but design the shape now, because the shape is the part that is expensive to change once real agents are running on top of it.

Akash Devdhar is a Senior Software Engineer specializing in enterprise identity, authentication, authorization, and AI infrastructure. He writes about building secure AI systems using OAuth, OIDC, RBAC, and modern identity architectures.

Authentication vs Authorization: Why Most AI Apps Get It Wrong

Akash Devdhar — Sat, 22 Aug 2026 15:14:02 +0000

Here is the failure mode I am seeing over and over in AI app reviews. The app checks who you are exactly once, at login, and after that it treats the agent as if it has a blank check for the rest of the session. Read a file, sure. Send an email, sure. Delete a record, why not, you logged in twenty minutes ago only. That is not an authorization model, that is a login screen pretending to be one.

Authentication and authorization are not the same question asked twice, they are two entirely different questions, and most AI apps are answering the first one and quietly skipping the second, forever, for the whole session.

The one question that gets asked, and the one that doesn't

Authentication happens once, at the door: who is this. The app checks a password, a session cookie, an SSO token, whatever, and it is satisfied. Fine so far, this part most teams actually get right.

Authorization is supposed to happen continuously, at every door inside the building: now that we know who this is, should this specific action, on this specific resource, right now, be allowed. This is the part that AI apps are skipping basically. Traditional web apps got away with checking authorization loosely because a human was the one clicking buttons, slowly, with natural friction built into every step. An AI agent has no such friction. It can chain fifteen tool calls in three seconds, and if your authorization model is "well, they logged in," every single one of those fifteen calls just inherited the same blank check.

What this actually looks like when it breaks

Say your AI assistant is authenticated as a support engineer who can read customer tickets. Somewhere in its tool list, there is also a "run_sql_query" tool, because someone needed it for a debugging session six months ago and nobody removed it. The authentication layer sees a valid, logged-in support engineer. It has no concept of "this specific tool call, on this specific table, for this specific reason, right now." So the agent runs the query. Not because anyone decided the support engineer should have that access for that task, but because nobody built the layer that would have stopped it.

This is exactly the gap that RBAC and, better, scoped OAuth tokens are supposed to close, and it is also exactly the gap that gets silently reintroduced when a team wires an agent up with one long-lived service account "to keep things simple."

What continuous authorization actually looks like

The difference is not exotic. Every tool call the agent makes should carry a scope, and something on the other end should actually check that scope before doing anything, every single time, not just once at session start. This is what OAuth 2.0 scopes were built for, and it is what the newer Rich Authorization Requests spec (RFC 9396) extends further, letting you express authorization at the level of "read tickets in this one project" rather than a flat "read tickets, all of them, everywhere."

A quick code example

Here is roughly what the one-time-gate version looks like, which is unfortunately close to what a lot of agent frameworks default to:

# Checked once, at session start, then trusted for everything after
def handle_tool_call(session, tool_name, args):
    if session.is_authenticated:
        return execute_tool(tool_name, args)
    raise PermissionError("not logged in")

And here is the per-action version, where the token's scope is actually checked against what the specific tool call is trying to do:

def handle_tool_call(session, tool_name, args):
    token = session.access_token  # short lived, scoped, from the OAuth flow
    required_scope = TOOL_SCOPE_MAP[tool_name]  # e.g. "tickets:read"

    if required_scope not in token.scopes:
        raise PermissionError(f"token lacks scope: {required_scope}")

    if not resource_matches_scope(args, token):
        # e.g. token is scoped to project_id=42, but the call targets project_id=17
        raise PermissionError("resource outside token's authorized scope")

    if token.is_expired():
        raise PermissionError("token expired, re-authorize")

    return execute_tool(tool_name, args)

The second version has more code, I know, but every one of those checks is answering a question the first version never even asked. Which tool, on which resource, under which still-valid grant.

Standards worth reading

RFC 6749, The OAuth 2.0 Authorization Framework, for the base scope model.
RFC 9396, OAuth 2.0 Rich Authorization Requests, for expressing authorization at a finer grain than a flat scope string.
NIST SP 800-207, Zero Trust Architecture, for the broader principle this post is really just a specific case of: never trust a request just because it came from an already-authenticated session, verify it again for the specific action being taken.

The takeaway

Logging someone in, or logging an agent in, answers exactly one question and that question is not "should this happen." If your AI app's entire authorization model is "well, the session is valid," you do not have authorization at all, you have authentication wearing a bigger hat. Check the action, not just the actor, and check it every time, not just at the door.

OAuth, OIDC, SAML, JWT: A Practical Guide for Modern Engineers

Akash Devdhar — Sat, 15 Aug 2026 18:19:56 +0000

I am asking engineers in interviews to explain the difference between OAuth and OIDC, and half the time I am getting the same answer basically: "they are both for login." That answer is wrong, and it is not a small wrong, it is the exact kind of wrong that is now showing up in how people are wiring up AI agents. Four acronyms, four different jobs, and treating them as one blob is where the actual security bugs come from.

Let me put it plainly. SAML and OIDC answer "who are you." OAuth answers "what are you allowed to do." JWT is not a protocol at all, it is just a format, a container that any of the above can choose to put its output in. If you remember only one sentence from this post, remember that one, full stop.

Authentication versus authorization, actually explained

Every confused conversation I have had on this topic traces back to mixing up two different questions.

Authentication is proving identity. You log into your company's SSO portal, it checks your credentials (maybe with an MFA prompt), and it tells the application "yes, this is genuinely Priya, verified." SAML and OIDC both live here. They are competing standards for the same job, not complements.

Authorization is a separate question that comes after: now that we know it is Priya, what is she actually permitted to do. Can she read this calendar. Can she call this API. Can her AI agent, acting for her, delete a record. OAuth 2.0 lives here, and only here. OAuth was never designed to answer "who is this," which is exactly why bolting OIDC on top of it (which is literally what OIDC is, an identity layer added on top of OAuth 2.0) was necessary in the first place.

JWT (RFC 7519) sits underneath both, as a token format. An OIDC ID token can be a JWT. An OAuth access token can be a JWT, or it can be an opaque reference string, both are valid, people forget this. SAML, being older, uses XML assertions instead of JWT, which is one of the practical reasons SAML feels clunky to work with compared to the newer JSON-based standards.

Where each one actually shows up

SAML: enterprise SSO, the classic case being logging into Salesforce or Workday through your company's identity provider. Heavy XML, browser redirect based, still everywhere in large enterprises even though nobody is excited about it anymore.
OIDC: modern consumer and enterprise login, "Sign in with Google" being the most familiar example. Built on OAuth 2.0, uses JSON and JWTs, much lighter than SAML.
OAuth 2.0: delegated authorization, letting an app or an agent act with limited permission on your behalf, without ever handing over your password. This is the one that matters most once agents enter the picture.
JWT: the token format that carries the actual claims (who, what scope, when it expires) in a compact, signable, verifiable way. Not a standard for login or authorization by itself, just the envelope.

Why this confusion gets expensive with AI agents

Here is the pattern I am actually seeing go wrong. A team builds an AI agent, the agent needs to call three internal services, and someone reaches for "let's just use SAML" or worse, "let's just give it a JWT" as if JWT alone was a security model. JWT is not a security model, it is a shipping container, what matters is who signed it, what claims are inside it, and who is checking those claims before trusting the box. An unsigned or unverified JWT is basically a sticky note that says "trust me."

The pattern that actually works: OIDC (or SAML, if you are stuck in an enterprise IdP that has not modernized) authenticates the human who is delegating work to the agent. OAuth 2.0, specifically client credentials or token exchange (RFC 8693) grants, authorizes the agent for a narrow, expiring scope. The resulting access token happens to be encoded as a JWT, so the resource server can verify it without a network round trip back to the issuer.

Notice that JWT is not doing any of the actual security work in that second diagram. It is the format the token happens to travel in. The security work is being done by OIDC establishing who the human is, and OAuth deciding what the agent gets to do on that human's behalf, for how long.

A quick code example

Decoding (not verifying, an important distinction) a JWT to see what is actually inside one:

import jwt  # PyJWT

# NEVER trust a token just because you can decode it.
# This only shows you the claims, it proves nothing by itself.
token = "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
claims = jwt.decode(token, options={"verify_signature": False})
print(claims)
# {'sub': 'agent-invoice-reader', 'scope': 'invoices:read',
#  'aud': 'https://api.internal-service.com', 'exp': 1735689600,
#  'iss': 'https://idp.example.com'}

And here is the part people skip, actually verifying it before trusting anything in it:

import jwt
from jwt import PyJWKClient

jwks_client = PyJWKClient("https://idp.example.com/.well-known/jwks.json")
signing_key = jwks_client.get_signing_key_from_jwt(token)

claims = jwt.decode(
    token,
    signing_key.key,
    algorithms=["RS256"],
    audience="https://api.internal-service.com",
    issuer="https://idp.example.com",
)
# Now the claims are actually trustworthy, because the signature,
# audience, and issuer were all checked, not just the payload read.

That second snippet is the whole point of this post basically. Decoding is free and proves nothing. Verifying against a trusted issuer's public key is the actual work, and it is where most homegrown "just use JWT" implementations quietly skip a step.

Standards worth reading, not just skimming

SAML 2.0 (OASIS standard) for the XML assertion based SSO model, still relevant in large enterprises.
OpenID Connect Core 1.0 for how identity got layered on top of OAuth 2.0.
RFC 6749, The OAuth 2.0 Authorization Framework, for the base delegation model.
RFC 7519, JSON Web Token (JWT), for the token format itself.
RFC 8693, OAuth 2.0 Token Exchange, for the agent-to-agent delegation case specifically.

The takeaway

Stop treating these four as synonyms with different logos. SAML and OIDC prove who someone is. OAuth decides what they, or their agent, can do. JWT is just the envelope the decision travels in, not the decision itself. The moment you are clear on which of these three jobs you are actually solving for, half the "how do we secure our AI agents" confusion in your team's Slack channel basically disappears on its own.

Why API Keys Are Not an Identity Strategy

Akash Devdhar — Mon, 10 Aug 2026 20:20:57 +0000

Every team building AI agents right now is basically doing the same thing: they generate a long random string, put it in an environment variable, call it “authentication,” and move on. I am seeing this pattern in almost every AI infrastructure discussion I am part of, and I want to say clearly: an API key is a secret, not an identity. Treating it as the same thing is a disaster waiting to happen.

The confusion, explained simply

A secret answers one question: do you know this string or not? An identity answers a completely different set of questions. Who are you, actually? What are you allowed to do? Who granted you that permission, and for how long? When an API key is your whole security model, you have answered the first question and quietly skipped the other three.

This was tolerable when the caller was a predictable backend service that your own team wrote and deployed. It is not tolerable when the caller is an AI agent that is making autonomous decisions, chaining tool calls, and sometimes acting on behalf of a human user it has never directly authenticated. The agent is not “your service” anymore in the old sense. It is closer to a semi-independent actor that needs its own verifiable identity, its own scoped permissions, and its own audit trail.

Where the API key model actually breaks

Let me list where I am seeing the cracks, without pretending this is some neat universal law:

No delegation. An API key cannot say “I am acting on behalf of user X, with X’s consent, for the next 15 minutes.” It is a flat, all-or-nothing credential.
No expiry that means anything. Most API keys live forever until someone remembers to rotate them, which basically means never.
No audience or scope binding. The same key that reads a customer record can usually also delete it. There is no built-in concept of “this token is only valid for this one resource server, for this one action.”
Terrible audit story. When three different AI agents share the same key—and in practice, they often do—your logs cannot tell you which agent actually did what. You get a name in a log line, not a proof.
Revocation is a blunt instrument. You cannot revoke “this one agent’s access to this one tool” without breaking everything else that shares the key.

None of this is a new problem, actually. Enterprise software went through this exact argument fifteen years ago when everyone moved off shared static credentials toward OAuth-based delegated access. What is different now is that the caller on the other end is not a human clicking “allow” on a consent screen; it is an autonomous agent, and the whole flow needs to happen without a human sitting there approving each step.

What an identity-based model looks like instead

In the API key model above, there is nothing to reason about. The key either works or it does not, and once it is compromised, everything behind it is compromised also. Now compare this to what a proper identity flow looks like for an agent.

The important shift here is that the agent is not holding a permanent secret that grants everything. It is holding a token, and that token is a claim about identity, scope, and time. The resource server does not trust the token because it is hard to guess; it trusts the token because it is signed by an identity provider it already trusts, and it can inspect exactly what the token is allowed to do before it does anything.

This is where OAuth 2.0 client credentials grant, or better, OAuth 2.0 token exchange (RFC 8693), becomes relevant for agent-to-agent and agent-to-tool calls. Token exchange in particular is built for exactly this situation: an agent that holds one token needs to call a downstream service with a narrower, more specific token, possibly acting on behalf of the original user. That is delegation done properly, not a shared secret pretending to be delegation.

A quick code comparison

Here is roughly what the API key version looks like. Simple, and also the whole problem in one snippet:

# The "identity strategy" most agents ship with today
import requests

response = requests.get(
    "https://api.internal-service.com/v1/customer-records",
    headers={"X-API-Key": "sk_live_9f8a7...never_rotated"}
)
# No subject, no scope, no expiry, no way to tell which agent called this.

Now compare with a token acquired through client credentials and passed as a bearer token, where the token itself carries claims:

import requests

token_response = requests.post(
    "https://idp.example.com/oauth/token",
    data={
        "grant_type": "client_credentials",
        "client_id": "agent-invoice-reader",
        "client_secret": AGENT_SECRET,  # short lived, rotated, scoped to this one agent
        "scope": "invoices:read",
        "audience": "https://api.internal-service.com",
    },
)
access_token = token_response.json()["access_token"]

response = requests.get(
    "https://api.internal-service.com/v1/customer-records",
    headers={"Authorization": f"Bearer {access_token}"},
)
# The token carries sub, scope, aud, and exp claims.
# The resource server can verify all four before doing anything.

The second version has more moving parts; I am not denying that. But those moving parts are exactly what let you answer “which agent did this, was it allowed to, and for how long” without guessing. If you decode that access token (it is typically a JWT, RFC 7519), you get a sub claim identifying the client, a scope claim limiting what it can do, an aud claim binding it to one resource server, and an exp claim that makes the whole thing self-expiring. An API key gives you none of these.

Standards worth actually reading

If you are designing this for real, three documents are worth your time and not just a skim:

RFC 6749, The OAuth 2.0 Authorization Framework, for the base grant types including client credentials.
RFC 8693, OAuth 2.0 Token Exchange, which is basically the spec that AI agent architectures keep re-inventing badly when they do not use it.
RFC 7519, JSON Web Token (JWT), for how claims-based tokens are structured and verified.

OpenID Connect is also worth knowing here, though it solves a slightly different problem: authenticating a human end user. Most agent-to-service calls are closer to pure OAuth client credentials or token exchange territory.

The takeaway

An API key tells you that a caller knows a string. It does not tell you who the caller is, what it is allowed to do, or when that permission runs out. AI agents are autonomous enough now that this gap is not theoretical anymore; it is showing up as real incidents. If your agent’s entire security model is one static header value, you do not have an identity strategy—you have a shared password with extra steps.

Treat your agents like the semi-independent actors they are: give them real, scoped, expiring identity, not a key copied into a config file three deployments ago.

OAuth Was Designed for Humans. AI Agents Change the Rules.

Akash Devdhar — Tue, 04 Aug 2026 18:18:52 +0000

I will say it plainly. OAuth 2.0, as good as it is, was never built with the idea that the “user” on the other end could be a software agent taking fifty decisions a minute without anybody watching. We have been bending the spec to fit agents, when actually the spec was assuming a human sitting in front of a browser, clicking “Allow.” That assumption is now breaking, and most teams building AI agents have not fully understood how much.

Let me explain what I mean.

The human assumption baked into OAuth

Classic OAuth 2.0 authorization code flow goes something like this. A user clicks login, gets redirected to an identity provider, sees a consent screen, clicks “Allow,” and comes back with an authorization code that the app exchanges for a token. Every single step in this flow assumes a human is present to look at a screen and make a judgment call.

Now put an AI agent in that loop. There is no browser session waiting on the agent’s side. There is no human eyeball reading “This app wants to access your calendar and email.” The agent is not clicking “Allow”; it is calling an API, and it needs to do this at 2 AM, unattended, sometimes chaining five or six calls to different services in a matter of seconds.

The three-legged OAuth dance was built for exactly one thing: a human giving informed consent, in the moment, for a specific access grant. Agents break this in at least three ways.

Where it actually breaks

1. No human present for consent at request time. Consent has to be captured upfront, or delegated in advance, because the agent cannot pause mid-task and wait for someone to click a button. This changes consent from an interactive, moment-of-request thing into a policy that has to be defined beforehand.

2. Identity gets layered, not singular. In classic OAuth, the token represents “this user, authorized this app, for this scope.” With agents, you actually have three identities stacked together: the human who initiated the task, the agent that is executing it, and sometimes a sub-agent that the first agent spawned to do a smaller piece of work. Standard OAuth tokens were not built to carry this chain.

3. Session lifetime assumptions do not hold. A human session might last an hour, a day at most, with natural boundaries like closing the laptop. An agent’s “session” could span a long-running workflow, spin off parallel sub-tasks, and outlive any reasonable human-session pattern, while still needing the same scoped, revocable access a human would get.

Here is the classic flow first, stripped down to its four essential hops:

One human decision point, right at the start, and one hop from app to resource. Simple.

Now look at what an agent delegation chain actually needs. The human still decides only once, upfront, but everything downstream has to be carried and enforced through tokens instead of another click:

Same one human decision at the top. But underneath it, two extra hops that a human never sees or approves in real time, and each one has to answer for itself through the token it is carrying, not through a person watching a screen.

What actually helps here

The good news is, we are not starting from zero. RFC 8693, the OAuth 2.0 Token Exchange spec, already gives us a pattern for “on-behalf-of” tokens, where one party can exchange a token for a narrower, downstream token while preserving a chain of who is acting for whom. This maps almost perfectly onto agent delegation, if teams actually use it instead of just minting a fresh static key for every agent.

A rough version of what this looks like in practice:

# Agent requests a narrower, short-lived token to call a downstream API,
# on behalf of the user who originally delegated the task.

response = requests.post(
    token_endpoint,
    data={
        "grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
        "subject_token": agent_session_token,
        "subject_token_type": "urn:ietf:params:oauth:token-type:access_token",
        "requested_token_type": "urn:ietf:params:oauth:token-type:access_token",
        "scope": "calendar.read",          # narrower than the agent's own scope
        "audience": "calendar-service",    # explicit downstream target
    },
)

downstream_token = response.json()["access_token"]
# This token should be short-lived, auditable, and traceable
# back to both the agent and the human who delegated the task.

Combine this with JWT-based claims (RFC 7519) carrying an explicit “acting on behalf of” field, and you get tokens that actually answer the question an auditor will ask you six months later: which agent did this, on whose authority, and with what scope?

There is also real movement happening around authentication patterns specifically for MCP servers, since MCP is quickly becoming the way agents talk to tools and data sources. Worth watching this space closely, because whatever pattern wins there will likely become the default for agent-to-tool auth industry-wide.

The takeaway

OAuth is not broken; it is just incomplete for this new kind of actor. The fix is not to throw it out. It is to extend it: upfront consent instead of interactive consent, token exchange for layered identity instead of one flat token, and short-lived scoped grants instead of a static key living in an environment file for six months.

If your agent architecture still treats the agent as “just another OAuth client” with a long-lived key, you are one incident away from finding out the hard way why the humans-only assumptions in OAuth mattered in the first place.

Authentication for AI Agents: Lessons We Can Borrow from Enterprise Identity

Akash Devdhar — Sun, 02 Aug 2026 14:44:24 +0000

Last week I was debugging an issue where our AI agent kept losing its session mid-task. And it struck me: we are basically solving the same problem enterprise IT teams solved 15 years back with SSO and IAM. The only difference is that this time the “user” logging in is not a human—it’s a piece of software making decisions on its own.

Most teams building AI agents right now are treating auth as an afterthought. An API key hardcoded somewhere, one service account shared across ten agents, nobody knowing which agent did what action. I have seen this pattern more than once now, and honestly, it is a disaster waiting to happen.

So let’s talk about what enterprise identity already figured out, and how we can borrow it.

1. Every identity, human or not, needs its own credential

In the enterprise world, we don’t let two employees share one login. The audit trail becomes useless, accountability goes out the window, basically. The same logic applies to agents. If Agent A and Agent B are sharing one API key, and something goes wrong, how will you even trace back which agent did the damage? Each agent should get its own machine identity, full stop.

2. Short-lived tokens over static keys

This one is not new. OAuth2 and SAML taught us this ages ago. A static API key sitting in an environment file for months is a ticking bomb. Agents should be requesting short-lived tokens, refreshing them, and the moment an agent’s task is done, that token should expire. Enterprise IAM tools like Okta or Azure AD do this for humans automatically; we need the equivalent for agents.

3. Least privilege is non-negotiable

I know it’s tempting to give your agent broad access “just in case it needs it later.” But this is exactly the mistake enterprises made in the early days, before RBAC became standard practice. An agent that only needs to read a calendar should not have write access to your entire email account. Scope it down, always.

4. Delegated authority needs to be explicit

This is where it gets interesting, actually. When an agent acts “on behalf of” a user, enterprise identity already has a pattern for this. OAuth’s delegation model, or even the older Kerberos constrained delegation. The agent should carry proof of who it’s acting for, not just its own identity. Otherwise, you can’t even answer the basic question: was this action authorized by the user, or did the agent go rogue on its own?

5. Continuous verification, not one-time login

Enterprises moved from “log in once, trust forever” to Zero Trust. Verify every request, every time, based on context. Agents are even more unpredictable than humans in their behaviour, so this applies double. Don’t authenticate an agent once at session start and forget about it; keep checking.

Honestly, none of this is very new thinking. The identity and access management folks have already fought this battle, made the mistakes, and written the standards for it. We are just now applying the same to a new kind of actor in the system.

What I am noticing is that a lot of AI infra teams are reinventing auth from scratch, when they could simply be adapting what already exists in the IAM world, with some tweaks for the fact that agents can act faster, more autonomously, and sometimes unpredictably compared to a human clicking buttons. Worth thinking about before the AI agent version of a credential leak becomes the next big headline.