DEV Community: Akash Devdhar

How Enterprise SSO Actually Works

Akash Devdhar — Wed, 30 Sep 2026 19:28:23 +0000

Enterprise SSO is usually explained as "log in once and access every application." That describes the user experience, but it hides the architecture so completely that teams start believing every application is sharing one giant session. They are not. Each application has its own session. What is shared is trust in the same identity provider, full stop.

This difference matters because SSO failures are rarely about the login screen. They happen when an application trusts the wrong issuer, accepts an assertion intended for somebody else, maps groups directly into permanent privilege, or assumes that signing out from one place has magically ended every session everywhere.

SSO is federation. One system proves that authentication happened, another system decides whether to accept that proof, and then the application creates local state of its own.

The identity provider does not log you into the application

Take a normal employee opening a software-as-a-service application. The application does not have the employee's password, and it should not ask for it. Instead, it redirects the browser to an identity provider, usually called the IdP. The IdP authenticates the user using whatever controls the enterprise requires, perhaps password, phishing-resistant MFA, device posture, or an existing IdP session.

After authentication, the IdP sends a signed response back through the browser. With SAML, that response contains a SAML assertion. With OpenID Connect, the application receives an authorization response, exchanges the authorization code at the token endpoint, and obtains an ID token.

The browser is carrying the response, but the browser is not what makes it trustworthy. The signature, issuer, audience, time bounds, request correlation, and protocol validation make it trustworthy.

Once the application validates the response, it maps the external identity to a local account and creates its own session cookie. On the next request, the application normally reads that local cookie. It does not redirect to the IdP every time only. This is why the application can remain signed in even when the IdP page is not open, and why logout becomes more complicated than login.

SAML and OIDC carry similar trust in different shapes

SAML 2.0 is still common in enterprise software. It uses signed XML assertions and browser POST or redirect bindings. The application is the Service Provider, or SP. The IdP sends an assertion containing a subject, an audience restriction, validity times, and attributes.

OpenID Connect is an identity layer built on OAuth 2.0. The application is an OIDC client, and the IdP is an OpenID Provider. Modern applications normally use the authorization code flow with PKCE. The ID token is usually a JWT, and the client can use the access token for a separate API when the design requires it.

They solve a similar SSO problem, but they are not interchangeable payload formats. SAML has assertion consumer service URLs, entity IDs, XML signatures, and metadata. OIDC has redirect URIs, client IDs, discovery metadata, JSON Web Keys, authorization codes, and ID-token validation. Wrapping both behind one "SSO callback" abstraction can be useful, but the validation rules must stay protocol specific.

The application should load trusted configuration from an administrative onboarding flow. It should not accept an arbitrary issuer or metadata URL from a login request. Otherwise the caller can choose which identity provider the application trusts, which is basically allowing the user to bring their own authority.

Validation is the real SSO implementation

Redirecting a browser is easy. Correctly deciding whether the returned identity proof belongs to this request and this application is the security work.

For OIDC, validate at least the issuer, audience, signature algorithm, expiry, and nonce. Correlate the state value with the browser session to defend the authorization response flow. Use an exact registered redirect URI. If the token contains multiple audiences, apply the protocol's authorized-party rules rather than picking the first value that looks familiar.

const tokenSet = await oidcClient.callback(
  "https://app.example.com/auth/callback",
  callbackParams,
  {
    state: loginAttempt.state,
    nonce: loginAttempt.nonce,
    code_verifier: loginAttempt.codeVerifier,
  },
);

const claims = tokenSet.claims();

if (claims.iss !== configuredIssuer) {
  throw new Error("unexpected identity provider");
}

const account = await accounts.resolveFederatedIdentity({
  issuer: claims.iss,
  subject: claims.sub,
});

The stable external identifier is the pair of issuer and subject, not email address by itself. Email can change, be reused, or collide across identity providers. Linking accounts by an unverified email is convenient right until one tenant's identity becomes another tenant's local account.

For SAML, validate the XML signature using the configured IdP certificate, the response destination, audience restriction, assertion validity, and request correlation such as InResponseTo when the flow expects it. Protect against XML signature wrapping by using a maintained SAML library and consuming only the element that the library verified. Searching the XML tree manually for a convenient NameID defeats the point of the signature.

The OIDC Core specification and SAML 2.0 Profiles define these checks because each one closes a different substitution or replay path. They are not optional decoration around the signature.

Account mapping is where tenants get crossed

After validation, the application has an external identity. It still has to answer a local question: which account and tenant does this identity belong to.

Enterprise applications often discover the tenant from the verified issuer or an explicit SSO connection selected before redirect. That connection maps one enterprise IdP to one application tenant. The returned email or domain may help onboarding, but it should not silently override the configured tenant boundary.

Just-in-time provisioning can create a local user after the first successful SSO response. SCIM can provision users and groups before login. These are lifecycle choices, not authentication shortcuts. Whether the account was created just in time or through SCIM, the application still needs a durable mapping and a clear disabled state.

Group and role claims need careful treatment also. An IdP group proves that the IdP placed the user in that group. It does not automatically mean the application should grant administrator access. Map external groups through tenant-owned policy, keep defaults narrow, and decide what happens when a claim disappears. Authorization remains an application responsibility.

This separation is useful during incidents. You can see whether the IdP authenticated the wrong person, the federation mapping selected the wrong local account, or the application granted the wrong permission. If everything is called "SSO," those three failures become one vague ticket.

SSO login is easier than SSO logout

Login works well because the browser follows a chain and every participant can create new state. Logout asks multiple independent systems to destroy state they own, sometimes when one of them is unavailable.

Signing out of the application should always end the application's local session. Redirecting to an IdP logout endpoint may end the IdP session, but it does not guarantee every other application session is gone. SAML Single Logout and OIDC logout specifications provide coordination mechanisms, but deployments vary and front-channel browser flows can fail.

For high-risk environments, do not rely on coordinated logout as the only revocation strategy. Keep local session lifetimes appropriate, consume deprovisioning events, and re-check sensitive authorization. If an employee is disabled at the IdP, an application session with a month-long lifetime should not remain trusted simply because no logout message arrived.

AI agents should not borrow the SSO session

An AI agent acting for an employee needs the human identity context, but the agent is not the human. Passing the browser session cookie into an agent process collapses two actors into one credential and makes the audit trail useless basically.

Use SSO to authenticate the human and establish the application's local session. When the user delegates a task, issue or exchange a separate short-lived credential for the agent. That credential should identify the workload, preserve the delegated subject, target one audience, and carry narrower scope. RFC 8693 token exchange is one useful pattern for this on-behalf-of relationship.

The distinction becomes important when the user logs out, the task is cancelled, or the agent delegates to a tool. The application can revoke the agent task without pretending the browser and the agent are one session. The resource API can log both who authorized the work and which workload actually performed it.

SSO answers how the human entered the trust system. It does not give every autonomous process permission to impersonate that human afterward.

The takeaway

Enterprise SSO is a chain of explicit trust decisions. The IdP authenticates the user and signs a protocol response. The application validates that response, maps the external identity into the correct tenant, and creates a local session. Then the application applies its own authorization policy.

SAML and OIDC make the exchange interoperable. They do not remove the need for strict validation, lifecycle management, or local access control. Once you see SSO as federation instead of a shared login, the architecture becomes much easier to reason about, and much harder to accidentally trust too broadly.

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.

Designing Secure Authentication APIs

Akash Devdhar — Wed, 23 Sep 2026 18:26:28 +0000

Many authentication APIs are basically one controller with very high confidence. Accept email and password, compare a hash, sign a JWT, return 200. Add HTTPS and rate limiting, then call it production ready. The endpoint may be only fifty lines, but those fifty lines are now issuing proof that every other service will trust. That is not a normal controller. It is a security protocol boundary, full stop.

What I am seeing is that teams are reviewing authentication APIs like business APIs. Does the input validate. Does the database query work. Does the happy path return the right JSON. Those questions matter, but the dangerous behavior is usually between requests: what an attacker can learn from failures, whether an old refresh token still works, which audience accepts the token, and what happens after the account is disabled.

The endpoint is smaller than the protocol

Consider the naive shape:

app.post("/login", async (req, res) => {
  const user = await users.findByEmail(req.body.email);

  if (!user) return res.status(404).json({ error: "user not found" });
  if (!await verifyPassword(req.body.password, user.passwordHash)) {
    return res.status(401).json({ error: "wrong password" });
  }

  const token = signJwt({ userId: user.id, role: user.role });
  return res.json({ token });
});

It works. It also reveals which email addresses exist, gives every resource server the same vaguely defined token, copies authorization into a credential with no freshness model, and has no visible session or refresh-token lifecycle. The bug is not one missing if statement. The API has no protocol around it.

Authentication design starts before password verification and continues after token issuance. Treat enrollment, recovery, MFA, login, refresh, logout, and revocation as one connected system. An account-recovery flow that bypasses MFA can defeat a perfectly implemented login endpoint. A refresh endpoint that accepts replay forever can undo a short access-token lifetime also.

Failure responses are part of the attack surface

Different errors make debugging pleasant and account enumeration easy. "User not found" and "incorrect password" tell an attacker whether the first guess was correct. Different response times can reveal the same thing even when the JSON is identical.

For public login and recovery endpoints, return a uniform external response for invalid credentials or unknown accounts. Internally, log the actual reason with appropriate access controls. When the account does not exist, perform a bounded password-hash operation using a fixed dummy hash so the timing shape stays reasonably close.

Rate limiting needs more than an IP address. Attackers distribute traffic, and shared corporate networks put many legitimate users behind one IP. Combine controls by source, account identifier, device or client signal, and overall risk. Apply progressive delay or step-up checks where appropriate. Do not turn rate limiting into a denial-of-service button where anyone can lock a victim's account by sending bad passwords.

The response should not explain your internal identity state. The audit trail should.

A token needs one meaning

"It is a valid JWT" is not a security decision. A JWT is a container. The resource server must know who issued it, which audience it targets, which algorithms are allowed, what token type it represents, and whether its time bounds are acceptable.

RFC 8725, the JSON Web Token Best Current Practices document, is clear about algorithm verification and cross-JWT confusion. An ID token should not accidentally work as an API access token. A token minted for the billing API should not work at the administration API just because both services know the same signing key.

Validation should be explicit:

const claims = await jwtVerify(rawToken, signingKey, {
  issuer: "https://identity.example.com",
  audience: "https://api.example.com/invoices",
  algorithms: ["ES256"],
  typ: "at+jwt",
  clockTolerance: 30,
});

if (claims.payload.token_use !== "access") {
  throw new Error("unexpected token type");
}

if (!hasRequiredScope(claims.payload.scope, "invoices:read")) {
  throw new Error("insufficient scope");
}

Do not let the token choose its own verification algorithm. Do not accept every audience your company owns. Do not make a resource server understand login-session cookies, ID tokens, access tokens, and internal agent tokens through one permissive parser. Separate token profiles make rejection easier to reason about.

Short access tokens need a real refresh design

Short-lived access tokens reduce the useful window after theft, but only if the refresh token is handled as the more powerful credential it is. A refresh token that lives for months, can be replayed repeatedly, and is stored beside the access token has not reduced much risk actually.

Rotate refresh tokens on every successful use. Store a hash of the current token, link tokens into a family, and treat reuse of an already-consumed token as a replay signal. Revoke the active family and require reauthentication rather than issuing one more access token to whichever party arrived second.

async function exchangeRefreshToken(presented: string) {
  const digest = hashToken(presented);

  return tokenStore.transaction(async (tx) => {
    const record = await tx.findForUpdate(digest);

    if (!record || record.revokedAt || record.expiresAt < Date.now()) {
      throw new Error("invalid refresh token");
    }

    if (record.consumedAt) {
      await tx.revokeFamily(record.familyId, Date.now());
      throw new Error("refresh token replay detected");
    }

    await tx.markConsumed(record.id, Date.now());
    return tx.issueSuccessor(record.familyId, record.subjectId);
  });
}

The transaction is important. Two refresh requests racing each other should not both receive valid successors. One succeeds. The other becomes evidence that the credential may have been copied.

Agents are not unusual users

When an AI agent needs an API, teams often send it through the human login endpoint using a service account. That creates a credential which looks like a person, has no delegation chain, and usually carries broad permissions because nobody can predict every task the agent may attempt.

Give workloads their own client identity. Use an OAuth grant appropriate for the actor, such as client credentials for the agent's own authority or token exchange from RFC 8693 when it acts on behalf of a user. Bind the resulting access token to one audience and narrow scopes. Keep the human subject and agent identity distinguishable in logs.

An agent session also needs a different lifetime. A browser may remain signed in for convenience, while an agent task should receive a credential bounded to the task and expire when the work should stop. Reusing the browser token is easy, but it makes logout, audit, and least privilege much harder only.

For high-risk machine-to-machine calls, sender-constrained tokens can reduce bearer-token theft. Mutual TLS and proof-of-possession approaches add operational work, so use them where the threat justifies it, but understand the tradeoff. A bearer token belongs to whoever holds it.

Recovery and revocation are authentication APIs too

Password reset, account recovery, device removal, and session revocation are sometimes built later by a different team. Attackers do not respect those ownership boundaries. They use whichever path produces trust most cheaply.

Recovery tokens should be single use, short lived, stored hashed, and scoped to the exact recovery action. Completing recovery should invalidate relevant sessions and refresh-token families. Changing a password without touching already issued credentials leaves the attacker signed in.

Revocation behavior needs a measurable target. If disabling an account must stop sensitive access within five minutes, access-token lifetimes, caches, long-lived connections, and background jobs must honor that window. Writing a disabled flag into the user table is not revocation until the services check it.

Audit every credential transition: issuance, failed authentication, MFA challenge, refresh rotation, replay detection, recovery, and revocation. Avoid logging raw passwords, session IDs, access tokens, or recovery secrets. An audit system that captures the credential itself becomes another credential store.

The takeaway

A secure authentication API does more than verify a password and sign a token. It controls what failures reveal, gives each token one precise meaning, detects refresh replay, and carries revocation through the rest of the architecture.

Treat human sessions, service identities, and delegated agent access as different credential flows. They can share identity infrastructure, but they should not share one ambiguous token. The API is issuing trust that other systems will act on, and that trust needs a protocol around it, not just a controller.

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.

Session Management at Scale

Akash Devdhar — Wed, 16 Sep 2026 18:14:18 +0000

Teams usually discover they have a session-management problem when Redis gets slow. They add replicas, tune TTLs, maybe shard by user ID, and declare the system scaled. The cache is faster, yes. The security model is still the same fragile one only.

A session is not just a cookie pointing at some server state. It is a live trust decision that has escaped the login service and started moving through your architecture. It reaches APIs, background workers, WebSocket connections, mobile devices, and now AI agents that can keep working after the user closes the browser. Scaling the lookup is the easy part. Scaling the meaning of that trust is where systems break.

Login creates a session, but the session keeps changing

At login time the picture looks clean. A user proves identity, perhaps completes MFA, and receives a session identifier. The server stores a record with the user, expiry, and maybe a few claims. Every request presents the cookie and the application loads the record.

Then reality arrives. The user changes organizations. An administrator removes a role. Risk signals require another MFA check. The user signs out one device but not another. A support team needs to revoke every active session after an account recovery. The original login was valid, but the authorization context around it is changing basically all the time.

If the session is a signed blob with a 30-day expiry and no server-side control, those changes wait 30 days also. Cryptographic validity is not the same as current authorization.

This is the first design decision that matters: what must be checked on every request, and what can safely remain fixed until expiry. User identity might be stable for the session. Tenant membership, account status, risk level, and sensitive permissions often are not.

Keep the browser credential small and meaningless

The browser should hold an opaque, high-entropy session identifier in a cookie with Secure, HttpOnly, and an appropriate SameSite policy. It should not hold the full authorization model in a value that every service learns to trust independently.

RFC 6265 defines cookie behavior, but cookie flags are only transport controls. They help protect the identifier. They do not solve rotation, revocation, or authorization freshness.

A server-side session record can stay compact:

type SessionRecord = {
  id: string;
  subjectId: string;
  tenantId: string;
  createdAt: number;
  lastSeenAt: number;
  idleExpiresAt: number;
  absoluteExpiresAt: number;
  authLevel: "password" | "mfa";
  version: number;
  revokedAt?: number;
};

Notice what is not there: a copied list of every permission the user had at login. Keep stable session facts in the record, then resolve authorization that can change from the current policy or membership source. Otherwise the session store becomes a warehouse of stale entitlements.

Rotation closes a window that expiry leaves open

Session expiry answers how long a credential may live. Rotation answers whether the same credential should survive a security boundary such as login, MFA completion, password reset, tenant switch, or privilege elevation.

Without rotation, an identifier captured before login can become an authenticated session after login. That is session fixation. Without rotation after privilege elevation, the same long-lived identifier moves from ordinary access to sensitive access with no new boundary around it.

The safe pattern is to create a new identifier and invalidate the old one atomically:

async function rotateSession(oldId: string, update: Partial<SessionRecord>) {
  return sessionStore.transaction(async (tx) => {
    const current = await tx.getForUpdate(oldId);

    if (!current || current.revokedAt) {
      throw new Error("session is no longer active");
    }

    const next = {
      ...current,
      ...update,
      id: crypto.randomUUID(),
      version: current.version + 1,
      lastSeenAt: Date.now(),
    };

    await tx.revoke(oldId, Date.now());
    await tx.insert(next);
    return next;
  });
}

Atomicity matters. If both identifiers remain valid during a race, rotation has created a second session rather than replacing the first one.

Revocation must reach every service

Central session storage gives you a revocation point, but only if every path actually checks it. A normal HTTP request may load the session on every call while a WebSocket authenticates once and remains connected for hours. A queued job may have copied the subject and tenant into its payload. An internal service may cache a successful session check for longer than the revocation target.

This is why a useful session design begins with a revocation objective. If disabling an account must stop sensitive actions within five minutes, every cache, connection, and worker must either revalidate inside five minutes or receive a reliable revocation event. Writing revokedAt into Redis does nothing for a process that never looks again.

For high-risk actions, check current session state immediately and require step-up authentication when the authentication level is not sufficient. For lower-risk reads, a short cache may be reasonable. The policy should be explicit. Accidental cache duration is not a security policy.

NIST SP 800-63B is useful here because it separates overall session lifetime from inactivity timeout and reauthentication requirements. Those controls should not collapse into one TTL field. An active session can still hit its absolute maximum, and a session inside its maximum can still require fresh authentication before a sensitive action.

AI agents create sessions inside sessions

An agent task is often treated as a background continuation of the user's browser session. The user starts a task, the agent receives some credentials, and it keeps running. But the browser session may end while the task is still making decisions. If the agent simply copied the original bearer token, logout becomes mostly cosmetic.

The agent needs its own bounded execution session. It should identify the workload, preserve who delegated the task, target one tenant, and carry only the scopes needed for that task. Its lifetime should reflect the work, not the user's browser-cookie lifetime. If it delegates to another agent or tool, the downstream credential should become narrower, not inherit everything.

OAuth 2.0 Token Exchange from RFC 8693 gives a useful pattern for creating that downstream credential. The browser session establishes the human context, but the agent receives a separate short-lived token with its own audience and traceable delegation. Revoking the task can then stop the agent without destroying every user session, and revoking the user can still cascade to active tasks when policy requires it.

This distinction also improves audit logs. "User 123 made API call" is incomplete when an autonomous workload performed the call twenty minutes after the user clicked a button. Record the session, agent identity, delegated subject, tenant, and task identifier. Otherwise all autonomous work becomes indistinguishable from direct human action.

Availability cannot quietly disable security

A centralized session store becomes critical infrastructure, so teams are tempted to fail open when it is unavailable. That turns an operational incident into an authorization bypass. If a service cannot determine whether a sensitive session is active, it should not assume active.

You can reduce the availability risk with replicas, regional stores, carefully bounded local caches, and signed short-lived proofs. But every optimization needs a maximum stale-trust window. A five-minute cache is a decision that revoked access may continue for five minutes. Sometimes that is acceptable. Pretending it is only a performance setting is not.

Monitor identity outcomes, not just cache latency. Track rejected expired sessions, revoked-session reuse, rotation failures, impossible tenant switches, and how long revocation takes to reach long-lived connections. A session system can have perfect uptime while authorization freshness is completely broken.

The takeaway

Session management at scale is the work of keeping trust current while it spreads. Store as little as possible in the browser, rotate identifiers when trust changes, separate idle and absolute lifetime, and make revocation reach every execution path inside a known window.

For AI agents, do not stretch a human browser session until it covers autonomous work. Create a smaller, traceable execution session with its own identity and expiry. The moment a session crosses a service boundary, it becomes identity architecture, full stop.

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.

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.