DEV Community: Anton Staykov

Your AI Agent Doesn't Need an API Key: Entra Agent ID and Anthropic's Workload Identity Federation

Anton Staykov — Thu, 21 May 2026 10:30:00 +0000

Your AI Agent Doesn't Need an API Key: Entra Agent ID and Anthropic's Workload Identity Federation

Every system that authenticates with a static API key is carrying a liability disguised as a convenience. The key does not expire unless someone sets a calendar reminder. It does not know who is using it. It cannot tell you whether the request that just hit the endpoint came from the production agent it was minted for or from a laptop in a coffee shop where someone pasted it into a terminal two months ago. Static keys are the skeleton key of modern distributed systems — they open the door for anyone who holds them, and they never ask why.

This is not a new problem, but it is becoming a dangerous one. As AI agents proliferate across enterprise environments — calling model APIs, orchestrating workflows, accessing downstream services — the number of static secrets embedded in configuration files, environment variables, and CI pipelines is growing faster than any rotation policy can keep up with. The question is no longer whether your organization has a leaked key somewhere. The question is how many, and which ones an attacker has already found.

The industry's answer has been converging for years, and it has a name.

Workload Identity Federation

Workload Identity Federation (WIF) is a pattern — not a product, not a proprietary protocol — built on top of OpenID Connect and the RFC 7523 JWT bearer grant. The idea is disarmingly simple: instead of minting a long-lived secret and handing it to a workload, you let the workload prove who it is using a short-lived, signed JSON Web Token issued by an identity provider (IdP) you already trust. The receiving system validates the JWT's signature against the IdP's published keys, checks the claims against rules you configured, and — if everything lines up — issues a short-lived access token in return. No secrets to store. No secrets to rotate. No secrets to leak.

The pattern has been adopted across the industry — by major cloud providers, CI/CD platforms, container orchestrators, and increasingly by model providers. Microsoft Entra, for its part, supports WIF both as an issuer (your Entra tenant issues JWTs that external systems trust) and as a relying party (your Entra tenant trusts JWTs from external identity providers to grant access to Entra-protected resources). That bidirectional capability is what makes the rest of this story possible.

Anthropic embraces the standard

Anthropic has brought native Workload Identity Federation support to the Claude API — and this deserves more attention than it has received.

With Anthropic's WIF implementation, any OIDC-capable identity provider can authenticate workloads to the Claude API without a static sk-ant-... key ever being involved. You register your IdP as a federation issuer in the Anthropic Console, define a federation rule that maps incoming JWT claims to a service account, and your workload does the rest: present the JWT, receive a short-lived Claude access token, call the API. The SDKs handle the exchange and the refresh loop. API keys can be disabled entirely on the Anthropic workspace.

Three concepts on the Anthropic side matter here:

Service accounts (svac_...) — non-human identities inside your Anthropic organization. A federated token acts as a service account. Unlike an API key, a service account has credentials minted for it on demand, and you can audit which workloads acted as which service account.
Federation issuers (fdis_...) — the registration of your OIDC identity provider with your Anthropic organization. Each issuer tells Anthropic "JWTs signed by this provider may assert workload identity for my org."
Federation rules (fdrl_...) — the bridge between an issuer and a service account: "when a JWT from issuer X has claims that look like Y, mint a token for service account Z."

The Console includes presets for common providers and a generic OIDC option that works with any standards-compliant issuer — including Microsoft Entra ID. That last bullet is the one this article cares about.

Microsoft Entra Agent ID — identity built for agents

Microsoft Entra Agent ID introduces first-class identity constructs purpose-built for AI agents. Not repurposed service principals. Not human user accounts pressed into service. Dedicated objects with a dedicated governance model.

The constructs that matter for this story:

Agent identity blueprints — the template and authentication foundation for one or more agent identities. The blueprint holds the credentials (client secret, certificate, or federated identity credential) and uses them to acquire tokens on behalf of all agent identities created from it. Conditional Access policies applied to a blueprint propagate to every agent identity it parents.
Agent identities — the runtime identity of a specific AI agent. An agent identity has no credentials of its own. It authenticates through its blueprint.
The Microsoft Entra SDK for Agent ID — a containerized sidecar that handles token acquisition, validation, and secure downstream API calls. Your agent code asks the sidecar for a token; the sidecar handles the identity plumbing.

The proof of concept

The question I wanted to answer was concrete: can an AI agent, using Microsoft Entra Agent ID as its native identity, call the Anthropic Claude API through Workload Identity Federation — with no API key, no certificate in agent memory, and no cloud LLM proxy in between?

The answer is yes. I built a proof of concept that does exactly this.

The architecture

The PoC runs as two containers on a Docker bridge network:

claude-wif-agent — a Flask application that receives user queries, asks the sidecar for an Entra JWT, exchanges that JWT for a Claude access token, and calls the Claude Messages API.
claude-wif-sidecar — the Microsoft Entra Auth SDK sidecar, which handles the client-credentials flow against Entra ID and returns a signed JWT scoped to the agent identity.

The token flow has nine steps, but the critical insight lives in three of them:

Steps 4–5: The sidecar uses the blueprint's credentials to obtain an Entra-issued JWT for the agent identity. The JWT carries the agent's appid, oid, and — crucially — the xms_par_app_azp optional claim that identifies the parent blueprint.
Step 7: The agent application exchanges that Entra JWT for a Claude access token by posting to POST https://api.anthropic.com/v1/oauth/token using the RFC 7523 jwt-bearer grant. Anthropic validates the JWT's signature, checks the claims against the federation rule, and returns a short-lived token.
Step 9: The agent calls POST https://api.anthropic.com/v1/messages with the Claude token. No API key is involved. No MSAL library is needed. No certificates sit in agent memory.

Three Entra objects — and why the third is easy to miss

The PoC requires three distinct Microsoft Entra objects. Two of them sound similar and the third is implicit in WIF mechanics — which is exactly why it trips people up.

An Agent Identity Blueprint — holds the credentials (client secret for local dev; managed identity or federated identity credential in production) and parents the agent identity.
An Agent Identity — the runtime identity of the specific AI agent. No credentials of its own — the blueprint mints tokens on its behalf.
An App Registration representing the Anthropic API — and this is the one that is easy to miss. Anthropic's WIF rule validates an Entra-issued JWT, and the only way that JWT carries the right aud (audience) claim is if Entra issues it for a registered resource application whose ID matches what you configured as the audience of the federation issuer in the Anthropic Console. This app registration uses v2.0 tokens (requestedAccessTokenVersion: 2), has acceptMappedClaims: true, and configures the xms_par_app_azp optional claim on the access token — so that a single Anthropic federation rule can match all agent identities parented by the same blueprint, rather than requiring a rule per individual agent.

The token that reaches Anthropic carries:

iss = https://login.microsoftonline.com/<tenant-id>/v2.0
aud = the Application ID of the Anthropic API app registration
appid = the Agent Identity's client ID
oid = the Agent Identity's object ID
xms_par_app_azp = the Agent Identity Blueprint's application ID

Anthropic validates all of this against the federation issuer and rule you configured. No Anthropic API key is involved at any point.

Both flows work

The PoC supports both access patterns that the agent identity platform defines:

Autonomous (app-only): The agent identity acts independently. The sidecar obtains a client-credentials token, the agent exchanges it for a Claude token, and the response comes back tagged "flow": "autonomous".
On-Behalf-Of (OBO): When a signed-in user's Entra Bearer token is available, the sidecar performs an OBO exchange and mints an agent-on-behalf-of-user token, which is then exchanged with Anthropic WIF. The response comes back tagged "flow": "obo".

Both flows use the same Anthropic WIF endpoint. The only difference is whose authority the Entra JWT represents — the agent's own, or the agent acting on behalf of a human.

From local dev to production

The PoC uses a client secret on the blueprint for local development — a pragmatic shortcut for proving the concept. Moving to production requires changing exactly two environment variables in the sidecar configuration to switch from client secret to managed identity, and adding a federated identity credential on the blueprint for the managed identity. No agent code changes. The sidecar abstracts the credential source entirely.

The credentials-free agent

This is where the threads converge. Workload Identity Federation is an industry standard. Anthropic has built native support for it into the Claude API. Microsoft Entra Agent ID provides purpose-built identity constructs for AI agents — with blueprints that centralize credential management, agent identities that carry no secrets of their own, and a sidecar SDK that abstracts the entire token lifecycle.

Put them together and you get something that would have been difficult to describe two years ago: an AI agent that authenticates to a third-party model provider using its own agentic identity, issued by the enterprise identity provider, validated through standards-based federation — with no static API key, no certificate in memory, and no cloud LLM proxy sitting in between. The agent's identity is its credential.

The proof of concept is open on GitHub: astaykov/claude-wif-agentid. It is minimal by design — a Flask app, a sidecar, a docker-compose.yml, and a .env file. The README walks through every Entra object, every Anthropic Console configuration step, and the full token flow. Fork it, break it, extend it.

The age of the static API key — for AI agents, at least — is ending. The identity infrastructure to replace it is already here.

References

Your Agent Is Becoming the Crown Jewel: SOC, Reviews, and Governance for the Dynamic-Consent Era

Anton Staykov — Mon, 18 May 2026 13:34:00 +0000

The previous article in this series argued that the combination of incremental and dynamic user consent and Microsoft Entra Agent ID gives interactive AI agents something genuinely new: the ability to earn their access in the wild, scope by scope, prompted by the humans and other agents they work alongside. Aria, the example agent, started with two delegated permissions and grew into a productive contributor across SharePoint, ServiceNow, and the Finance API in roughly a quarter — without its creators pre-declaring any of it.

That was the optimistic half. This is the other half.

By the end of that quarter, Aria is — by any reasonable measurement — the most over-privileged identity in the tenant. No one noticed, because there was nothing to notice. Every grant was legitimate, contextual, and user-approved. The risk did not arrive in a single bad decision. It arrived as a hundred reasonable yeses.

A different kind of over-permissioning

Classic over-permissioning is an event. Someone hands a service account Directory.ReadWrite.All because the deployment was due Friday, an auditor flags it months later, a ticket is opened. Slow, but the control loop exists, and it is built around discrete moments of poor judgment.

Permission accumulation through dynamic consent is structurally different. There is no single bad decision to find. The permission graph grows monotonically — one narrow, well-justified scope at a time — because the mechanism that makes the agent useful is the same mechanism that makes it dangerous. Nothing in the platform prunes that graph by default, and nothing in most organizations does either: access-review tooling was designed around human role changes, not around agents whose role is to absorb new capabilities.

Why agents become the target

A compromised agent identity is qualitatively worse than a compromised user account, and the reasons are worth stating plainly.

A user holds permissions scattered across teams, sick days, role changes, and eventual departures. Their access constantly churns, and the blast radius of any single compromise is naturally bounded by the messiness of human work.

An agent does none of that. It persists. It centralizes. Every scope a hundred different users granted to it is reachable through one set of tokens, one blueprint, one set of credentials issued by that blueprint. Add the realistic threat surface of a modern agent — token theft, blueprint compromise, prompt injection used as a lateral-movement primitive — and the picture becomes uncomfortable: the most attractive principal in the tenant is also the one whose authority grew quietly enough to escape notice.

What the SOC must change

Most security operations centers treat sign-in logs as the primary identity signal. For agents under dynamic consent, that is no longer sufficient. The consent log itself becomes a first-class detection surface.

Three signal families deserve attention:

Scope-acquisition velocity. A productive agent acquires new scopes in bursts that follow human work. An agent that suddenly requests broad scopes — especially ones approaching admin-consent thresholds — outside its normal pattern is worth waking someone up for.
Grant-versus-use gap. Scopes that were granted but are never exercised are liability at best, pre-positioned capability for an attacker at worst. Track them, and feed the gap into automated revocation.
Introduction chains. When agent A pulls agent B into a workflow and B requests new scopes as a result, that chain is part of the audit story. SOC tooling needs to render it as a graph, not as isolated events.

None of these are exotic. They are sign-in analytics one layer up the stack.

What in identity governance must change

Access reviews built for humans assume a relatively stable role. The reviewer is asked, in effect, "does this person still need what they had last quarter?" That question does not work for an agent whose entire purpose is to absorb new capabilities continuously.

Three adjustments are required.

Reviews keyed to recent use, not recent grant. The relevant question is no longer "should the agent have this scope?" but "did the agent actually exercise this scope in the last N days, and was the use consistent with the original justification?" Scopes that fail both halves of that test should expire automatically.

Owners and sponsors as the accountable humans. Microsoft Entra Agent ID separates technical owners from business sponsors precisely so that someone with operational context and someone with business context can both be on the hook. Wire those roles into the review workflow. An agent without a current sponsor should not be holding sensitive delegated permissions.

Blueprint-level Conditional Access as the choke point. Because policies applied to a blueprint propagate to every agent identity created from it, the blueprint is the right place to enforce the constraints that should never be negotiable — geographic boundaries, sensitive-resource exclusions, step-up requirements for specific scope families. Treat the blueprint the way you treat a privileged-access workstation: small, hardened, watched.

A governance posture that grows with the agent

Three principles are worth taking back to the architecture board.

Consent is telemetry. Treat every dynamic consent event as a security signal of equal weight to a sign-in. Pipe it into the same analytics and the same review workflows.

Least privilege is a verb, not a noun. A static least-privilege list cannot survive contact with an agent that earns its access. The control objective is no longer to define the minimum scope set — it is to continuously prune toward it.

Grow with the agent; do not be the hurdle. The organizations that succeed will be the ones whose governance moves at the same cadence as the agent's learning. Quarterly reviews and annual recertifications were already too slow for humans. They are unworkable for agents.

Aria is going to keep growing. So will every other interactive agent in the tenant. The question for identity and security architects is not whether to allow it — that decision has already been made by the people on the other side of the chat window. The question is whether the controls, the detections, and the operating model are ready for what dynamic consent has quietly enabled.

If they are not yet, that is the work for this year.

The Overlooked Gem in Microsoft Entra That Gives Your AI Agents Super-Powers

Anton Staykov — Sat, 09 May 2026 13:41:16 +0000

Most enterprise conversations about Microsoft Entra stop at the obvious: single sign-on, multifactor authentication, Conditional Access, a handful of well-policed app registrations. Useful, mature, well understood. And almost entirely beside the point for what is about to happen inside every large organization.

Buried in the Microsoft identity platform developer documentation sits one short section that quietly rewires what an AI agent can become inside an enterprise. It is not a new product. It does not have a launch event. It is a paragraph titled Incremental and dynamic user consent, and it is the most underrated capability in the Microsoft Entra surface area for the agentic era.

A 30-second consent primer

Microsoft Entra exposes three broad consent shapes, all covered in the same developer consent guide:

Static consent. Every permission an application could ever need is declared up front in the app registration. Tidy, predictable, and brittle — users and admins are asked to approve the entire future of the app on day one.
Admin consent. A tenant administrator approves a permission set on behalf of the whole organization. Necessary for application permissions and for sensitive delegated scopes.
Incremental and dynamic user consent. The application requests a minimal set of scopes at first and then asks for additional delegated permissions over time, exactly when a feature needs them, by including the new scopes in the scope parameter of an authorization request. The user approves in context. Crucially, this mechanism applies to delegated permissions — permissions exercised on behalf of a signed-in human.

That last constraint is normally treated as a footnote. For AI agents it is the entire story.

From applications to agents

The other piece of the puzzle is Microsoft Entra Agent ID. Microsoft Entra Agent ID introduces first-class identity constructs for AI agents — agent identities, agent identity blueprints, owners, sponsors, managers — and a purpose-built agent's user account: an optional user object paired 1:1 with an agent identity, for systems (Exchange Online mailboxes, Teams channels, and similar) that require a user principal. A deliberate construct, so agents can participate in user-shaped systems without being misrepresented as humans.

On top of that, the industry designs AI Agents with two main data access patterns:

Autonomous access act as themselves, with their own authorizations on workloads, with or without human in the loop.
Interactive access sign a user in, and act on that user's behalf through a chat-style interface, using delegated permissions.

Read those points together. Interactive agents live on delegated permissions. Dynamic consent is the only Microsoft Entra mechanism that lets delegated permissions grow organically after deployment. The two features were designed for different reasons, in different teams, at different times. They meet exactly where the modern AI agent operates.

Meet Aria

Consider Aria, an internal productivity agent built on Microsoft Entra Agent ID, deployed as an interactive agent behind a corporate chat surface. Aria's blueprint ships with the bare minimum: User.Read and offline_access. On day one, Aria literally knows nothing about the tenant's systems and can do nothing inside them.

Then work happens.

In the first week, a product manager asks Aria to summarize discussions on a SharePoint site. Aria does not have that scope. Instead of failing, the runtime issues an authorization request that includes Sites.Read.All. The user sees a contextual consent prompt, approves it in the moment, and Aria returns the summary.

In the third week, a separate workflow agent invites Aria into a ticket-triage loop and points it at a ServiceNow connector. Aria requests a narrow read scope on incidents. The on-call engineer approves.

In the sixth week, a finance analyst asks Aria to reconcile an invoice against a vendor record. Aria requests a tightly scoped read permission on the Finance API. The analyst approves.

At no point did Aria's creators have to sit down and pre-declare Aria's world. Aria grew because humans and other agents pulled it into their work, and Microsoft Entra provided the mechanism for each step of that growth to be explicit, recorded, and reversible.

The mental model shift

Static permissions are a job description written before a new hire arrives. Whoever writes the description has to imagine every meeting that hire will ever attend, every system they will ever touch, every workflow they will ever join. The description is always wrong, usually in both directions: too narrow to be useful and, in places, too broad to be safe.

Dynamic consent is a different metaphor entirely. The agent earns scope by being useful. Three discovery vectors drive the growth:

Human delegation in context. A user asks the agent to do something it cannot yet do. The consent prompt becomes part of the act of asking.
Cross-agent introduction. Other agents — orchestrators, copilots, MCP-style tool surfaces — pull the agent into flows it did not know existed and surface the resources it needs.
Self-discovery. The agent encounters a tool catalog or an API description and recognizes a capability worth requesting.

This is not exotic. It is exactly how a competent new hire becomes productive in a complex organization: they are introduced to systems, granted access on demand, and gradually accumulate the reach required to contribute. Microsoft Entra is finally letting our non-human colleagues follow the same path.

The cliffhanger

After one quarter, Aria looks very different from the agent that booted with two scopes. It holds dozens of delegated permissions across half the enterprise — every single one of them granted legitimately, in context, by a real human, against a recorded purpose.

That is the fascinating half. The other half is that Aria is now, by any reasonable measure, the most over-privileged identity in the tenant — and nobody noticed, because there was no single moment of bad judgment to notice. Just a hundred reasonable yeses.

That accumulation is the crown jewel an adversary will eventually come looking for. It is also the thing your access reviews, your SOC playbooks, and your governance model were not designed to see.

That is the subject of the next article in this series: what changes in detection, in identity governance, and in the operating model of the security organization once dynamic consent meets agent identity at scale.

The gem is real. So is the bill that comes with it.

Paying to Be the Product: The AI Privacy Illusion Nobody's Talking About

Anton Staykov — Mon, 27 Apr 2026 13:17:33 +0000

In tech, we've always said: "If you're not paying for the product — you are the product." In today's AI reality, that statement needs an update: we are paying to be the product.

I spend my days working in identity and security at Microsoft. But when I go home, I'm just another consumer — using AI assistants across every major platform, paying for premium tiers, trusting that my subscription buys me not just better answers, but basic respect for my data.

That trust led me down a rabbit hole I didn't expect.

The Moment That Started This

A few weeks ago, I was reviewing the privacy settings on Google Gemini Advanced — a service I pay for — and I realized something unsettling. To opt out of having my conversations used for AI model training, I had to turn off "Keep Activity". Sounds reasonable, right?

Except turning off Keep Activity doesn't just stop training. It disables everything: chat history, personalization, context across sessions, the ability to revisit old conversations. Every interaction becomes a blank slate. The AI assistant I'm paying a premium for becomes, functionally, lobotomized.

The choice Google presents to its paying customers is:

Option A: Full-featured Gemini that uses your data to train models.
Option B: A crippled Gemini that remembers nothing — but hey, your data isn't used for training. Mostly.

I'll come back to that "mostly" in a moment.

This bothered me enough that I decided to audit the privacy policies of every major AI assistant I use. Not surface-level marketing claims — the actual terms, the actual privacy notices, the actual small print.

What I found was... illuminating.

The Audit: Six Providers, One Question

The question was simple: As a paying individual consumer, can I opt out of my data being used to train AI models without degrading the service I'm paying for?

I examined: Google Gemini, OpenAI ChatGPT, Anthropic Claude, Microsoft Copilot, Mistral Le Chat, and Perplexity.

The Good News

Every single provider now offers some form of opt-out mechanism for consumers. That's progress. A year or two ago, that wasn't the case across the board.

The Bad News

The devil is in the details — and those details vary wildly.

What the Small Print Actually Says

Google Gemini: The Opt-Out That Costs You the Product

Google's Gemini Apps Privacy Notice deserves close reading — because the more you read, the less clear it becomes.

The only mechanism to opt out of AI model training is to turn off "Keep Activity". Here's what that actually does:

❌ Your chat history is no longer saved — chats are retained for 72 hours, then deleted
❌ No personalization — Gemini doesn't learn from your past conversations
❌ No context across sessions — every chat starts from zero
❌ You can't go back to old conversations — they're gone after 72 hours

On every other platform I tested, opting out of training is a standalone toggle. You keep your history, your personalization, your context. On Gemini, opting out of training means opting out of the product being useful.

But it gets more interesting. Google's own documentation appears to contradict itself on the same page.

In the "Configuring your settings" section, the Privacy Notice states:

"The settings in Gemini Apps Activity **don't control processing of your chats to create anonymized data* to improve Google services."*

This suggests anonymized data still feeds into service improvement — which Google defines elsewhere on the same page as including "generative AI models and other machine-learning technologies."

Yet in the FAQ section on the very same page, under "What does the Keep Activity setting control?":

"If Keep Activity is off and you don't submit feedback, Google also **does not use your future chats to improve its AI models."

These two statements are in tension. Does anonymized data still get used for model improvement when Keep Activity is off, or doesn't it? Google's own privacy documentation gives you both answers on the same page.

And regardless of which interpretation you trust, one clause remains unambiguous — under "How long we retain your data":

"Chats reviewed by human reviewers (and related data like your language, device type, location info, or feedback) **are not deleted when you delete your activity. Instead, they are retained for **up to three years."

To summarize: the only opt-out available degrades your paid product to near-uselessness, the documentation contradicts itself on whether anonymized data is still used, and human-reviewed chats persist for three years even after you delete them.

As a paying customer, this doesn't feel like a privacy control. It feels like an illusion of control — wrapped in contradictory language that would require a lawyer to parse.

📄 Gemini Apps Privacy Notice · Google Privacy Policy

OpenAI ChatGPT: Clean Opt-Out, One Loophole

OpenAI's approach is significantly better. The "Improve the model for everyone" toggle under Settings > Data Controls is independent of your chat history. You can keep your conversations, keep your context, and still opt out of training.

But there's a catch, documented in their own help center:

"Even if you have opted out of training, you can still choose to provide feedback... If you choose to provide feedback, **the entire conversation associated with that feedback may be used to train our models."

That thumbs-up button you casually tap? It potentially feeds your entire conversation into the training pipeline — even if you've opted out.

📄 OpenAI Terms of Use · How your data is used to improve model performance

Anthropic Claude: Honest About Its Exceptions

Anthropic updated its consumer terms in August 2025, and to their credit, they're transparent about what opt-out does and doesn't cover. From Section 4 of their Consumer Terms:

"We may use Materials to provide, maintain, and improve the Services... **unless you opt out* of training through your account settings. Even if you opt out, we will use Materials for model training when: (1) you provide Feedback to us regarding any Materials, or (2) your Materials are flagged for safety review..."*

Two explicit carve-outs. But at least they tell you upfront, and the opt-out doesn't degrade your service.

📄 Anthropic Consumer Terms · Anthropic Privacy Policy

Microsoft Copilot: Separate Toggles, No Training Carve-Outs

Full disclosure: I work at Microsoft. I'm including Copilot because excluding it would be intellectually dishonest, and my job doesn't exempt me from critical evaluation.

Copilot offers independent toggles for personalization, memory, and model training. The Copilot Privacy Controls page states:

"Opting out will exclude your future conversation activities from being used for training these AI models."

There's a caveat that data may still be used for "general product or system improvements... digital safety, security, and compliance" — but this is explicitly separated from model training.

📄 Microsoft Services Agreement · Copilot Privacy Controls

Mistral Le Chat: The GDPR Advantage

Being a French/EU company subject to GDPR, Mistral's approach is notably clean. The training opt-out is a simple toggle — independent of chat functionality. Paid Pro users are opted out by default.

The one caveat: user feedback (ratings/comments) is always used regardless of your opt-out setting. But chat content, uploaded documents, and conversation history are respected.

📄 Mistral Terms of Service · Mistral Opt-Out FAQ

Perplexity: The Wildcard

Perplexity offers an opt-out toggle for AI data retention, but the company is currently facing a class-action lawsuit alleging that user data — including conversations in "Incognito" mode — was shared with Meta and Google for ad targeting regardless of privacy settings.

The lawsuit is ongoing, and allegations aren't findings. But it's a reminder that a toggle in a settings page is only as trustworthy as the infrastructure behind it.

📄 Perplexity Terms of Service · Perplexity Privacy Policy

The Summary That Should Concern You

Provider	Opt-out degrades service?	Data still used after opt-out?	Exceptions
Google Gemini	❌ Yes — kills history & personalization	⚠️ Contradictory — documentation says both yes and no	3-year retention of reviewed chats; contradictory policy language
OpenAI ChatGPT	✅ No	⚠️ Feedback triggers training	Thumbs up/down = full conversation
Anthropic Claude	✅ No	⚠️ Feedback + safety flags	Explicitly documented
Microsoft Copilot	✅ No	✅ No carve-outs for training	Safety/compliance retention only
Mistral Le Chat	✅ No	✅ No (paid users auto-opted-out)	Feedback always used
Perplexity	✅ No	⚠️ Under litigation	Alleged sharing despite settings

Where Is the EU on This?

Here's what genuinely surprises me.

I've spent years grumbling about EU cookie consent banners. Every website, every visit, the same tedious popups — all in the name of protecting consumer privacy for a few tracking pixels.

Yet here we are in 2026, and AI providers are training models on paying consumers' conversations with opt-out mechanisms that range from "genuine but imperfect" to "functionally deceptive" — and the regulatory silence is deafening.

The GDPR was designed for exactly this scenario. Article 21 grants the right to object to data processing. Article 7 requires that consent be as easy to withdraw as it is to give. When Google forces you to choose between a functional product and privacy, is that really free consent?

I'm not calling for more regulation for the sake of it — heaven knows we have enough cookie banners. But if Europe's privacy framework means anything, this is precisely where it should be applied. Not to cookies. To the AI models being trained on our most intimate conversations with technology.

What I Want You to Take Away

This isn't a "don't use AI" article. I use all of these tools daily. They're transformative. But:

Check your settings. Today. Most providers default to training-on. The opt-out exists, but you have to find it and flip it yourself.
Read the exceptions. An opt-out toggle means nothing if the small print carves out half your data anyway. Know what "opt-out" actually means for each provider you use.
Be thoughtful about feedback. That casual thumbs-up on a response? On some platforms, it opens your entire conversation to training — even if you've opted out.
Evaluate whether your paid tier actually buys you privacy. For some providers, it does. For others, you're just paying for better answers while your data flows into the same training pipeline as free users.
Demand better. As consumers, as technologists, as an industry. The right to use a product you pay for without surrendering your conversations to model training shouldn't be a premium feature. It should be the default.

The research in this article reflects publicly available terms of service and privacy policies as of April 2026. All quotes are sourced directly from official provider documentation, linked inline. Views expressed are my own and do not represent my employer.

From OBO APIs to Agent Identities: Entra Conditional Access Still Works the Same

Anton Staykov — Mon, 16 Mar 2026 22:09:21 +0000

Six years ago I wrote a small sample to help me better understand how the On-Behalf-Of (OBO) flow actually works — a browser SPA calling a middle-tier Web API, which called Azure SQL on behalf of the signed-in user. Today it might be an assistive AI agent calling a MCP Server with the delegated constrains of the end-user. Same rules apply. This article explains why.

Three sentences that should survive beyond any particular technology:

If your system acts on behalf of a user, delegation rules apply.
If delegation rules apply, Conditional Access applies at token issuance for the downstream resource.
APIs, agents, and MCP servers don't change that — they just change the shape of the middle tier.

If an AI agent acts on behalf of a user, your existing Conditional Access policies that govern how users access corporate data already apply — automatically. You don't need to invent "agent-specific Conditional Access" for assistive agents. Assistive agents don't bypass Conditional Access. They inherit it.

If you understand OBO and Conditional Access from classic Web APIs, you already understand how Entra Agent ID behaves for assistive AI agents. Delegation semantics didn't change. Conditional Access behavior didn't change. Only the shape of the middle tier changed.

1. The Classic Delegated Access Pattern

The baseline architecture is the standard delegated access chain:

User
  ↓
SPA (interactive client)
  ↓  access token  [aud = Web API]
Web API (confidential client)
  ↓  OBO token     [aud = Resource]
Azure SQL  |  MCP Server

Two facts to hold firmly:

The Web API never authenticates as itself to the downstream resource. It always acts on behalf of the signed-in user.
The downstream resource — Azure SQL, Microsoft Graph, or an MCP server — sees a delegated token. It evaluates the user's identity and the delegated scopes. Conditional Access policies have already been enforced by Entra during token issuance.

2. The Web API has a real identity — and delegation is explicitly granted

This is the detail most diagrams omit, and it matters in production.

The Web API is not just "code that runs somewhere". In Microsoft Entra it is a registered application with its own identity. That identity authenticates to the token endpoint as a confidential client, using a client secret or certificate.

In a real OBO implementation, the Web API does two things simultaneously:

Authenticates as itself — proving "I am the Web API" using its own credentials.
Requests a delegated token for the downstream resource on behalf of the user, presenting the incoming user token as an assertion.

Critically, the capability to do OBO is not implicit. The Web API's identity must be explicitly granted the delegated permissions (scopes) for the downstream resource. The tenant administrator grants this; the Web API cannot do it on its own authority.

Practical framing: the Web API authenticates as itself, but it can only mint delegated tokens because the tenant has explicitly authorized it to act on the user's behalf for the specific downstream resource.

3. OBO in 90 Seconds

The flow has three steps:

The user signs in to the client and the client receives an access token whose audience is the Web API. The client uses that access token to call the Web API.
The Web API calls the token endpoint and exchanges that client token for a new one.
The resulting token is minted for the downstream resource and carries the user's identity from step 1 and delegated scopes from step 2.

In protocol terms, the exchange looks like this:

POST /<tenant_id>/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=<incoming_user_access_token>
&requested_token_use=on_behalf_of
&scope=https://database.windows.net/.default
&client_id=<api_client_id>
&client_secret=<api_client_secret>

Note both elements in the same request: client authentication (client_id + client_secret) and the user assertion (assertion). Both are required.

The invariant: OBO is strictly delegated. It uses delegated scopes, not application roles. Application permissions are not involved.

4. Conditional Access: who is targeted vs. who "feels" it

This is where real misunderstanding happens — and the confusion compounds when agents enter the picture.

Rule 1 — CA is assigned to the user and targets the resource.
A Conditional Access policy that requires MFA to access Azure SQL (or an MCP Server) is scoped to the user and the downstream resource. Evaluation happens when Microsoft Entra issues the delegated token for that resource — at the moment the OBO token is minted. Not when the user signs into the SPA. Not when the middle tier starts up.

Rule 2 — The middle tier is not a CA subject.
Even though the Web API has its own registered identity, it is not the subject of a CA policy intended to govern how users access corporate data. The CA policy constrains the user's access, not the middle-tier service identity. This remains true regardless of what the middle tier is: Web API, assistive AI Agent, MCP Server, or anything else.

Rule 3 — The middle tier still experiences CA outcomes.
When the Web API calls the token endpoint to acquire an OBO token, CA enforcement happens there. If CA requires step-up (like MFA), the token endpoint returns interaction_required with a claims challenge. The middle tier cannot satisfy this itself. It must surface this challenge back to the interactive client (the SPA in our case). The user performs the MFA, the client obtains a new token, and the middle tier retries the OBO exchange.

The one-liner: the middle tier is a CA messenger, not a CA subject.

5. Replacing the Web API with an (assistive) AI Agent (with an Agent Identity)

The transition to Entra Agent ID is explicit and mechanical:

Role	Classic World	Agentic World
Middle Actor	Web API	AI Agent
Identity Type	app reg.	Agent Identity
Access Mode	Delegated (OBO)	Delegated (OBO)
CA Evaluation	On the resource	On the resource

Nothing in the right column is new behavior. When using Entra Agent ID in delegated mode — the appropriate mode for an assistive agent acting on behalf of a signed-in user — three requirements apply:

The Agent Identity must be granted the delegated permissions needed for the downstream resource.
The Agent Identity acquires a delegated token representing the user, carrying their identity and scopes.
The Agent Identity is constrained by Conditional Access policies that govern the user's access to that resource.

The core continuity: you replaced the middle-tier actor, not the trust boundary.

6. MCP Server as the Downstream Resource

MCP servers can feel "agent-native," which leads engineers to assume the security model has changed around them. It hasn't.

An MCP Server is an OAuth-protected resource — a server that accepts access tokens.

Do not pass tokens through. Equally valid for the AI agent acting on-behalf-of the user, but also for an MCP Server requesting authorizations to further resources on-behalf-of the user.

Beyond that, whether the downstream resource is Azure SQL, Microsoft Graph, or anything else, the CA and delegation rules are identical. From Microsoft Entra's perspective it is an OAuth-protected resource. Tokens are issued for it, delegated permissions are scoped to it, and Conditional Access policies target it.

7. What to Actually Configure

Model your chain. Identify the downstream resource (REST API or MCP server) and the middle actor (Web API or agent identity in delegated mode).
Make delegation explicit. Confirm the middle actor is granted the delegated permissions required for the downstream resource.
Treat CA challenges as a product requirement. Expect interaction_required responses and claims challenges during downstream token acquisition. In your agent's backend, implement a handler for MsalUiRequiredException (for example). Design the user interaction path to satisfy step-up — do not swallow these errors.
Never pass tokens through. Validate the incoming token for the agent audience, then acquire a fresh token for any downstream resource.