Skip to content

Identity

Can an AI agent have an identity without an IdP?

You can give an AI agent a real, traceable agent identity without an identity provider — no IdP, no new secrets, no infrastructure at all — and still answer "which agent did this?" within your own systems from the very first run. Most identity advice skips straight to the hard part: register the agent in Entra, mint short-lived JWTs, verify them with JWKS. That's the right destination for a fleet calling protected APIs, but it's a non-starter on an air-gapped network or in an early-stage prototype where there is no directory to register anything in yet. Promptise Foundry's AgentIdentity is deliberately two-tier: it starts as a local identity that costs nothing to stand up, already stamps attribution onto everything the agent does, and upgrades in place to a verifiable, IdP-backed credential the day you actually need one.

Which AI agent did this? Attribution for agent fleets

AI agent action attribution is the forensic question every autonomous fleet eventually has to answer: when a refund was issued, a record was deleted, or a customer's data was exported, which agent did it? If your fleet shares one API key and one model credential, the honest answer is "the model" — and "the model did it" is not a sentence a SOC 2 or ISO reviewer will accept as attribution. This post frames attribution as a forensics problem rather than a logging convenience, and shows the two properties a record needs to actually survive an incident: the acting agent stamped on every action, and a verified principal landing in a tamper-evident log.

AI Agent Identity & Authentication: The Complete Guide

AI agent identity is the answer to a deceptively simple question: which agent did this? If you searched for "AI agent authentication" and landed on a page about storing your OpenAI key safely, you found the wrong thing — that secures the model call, not the actor. This guide separates the two clearly, explains why an autonomous agent is a new kind of non-human actor that needs its own identity, and shows you how to give one a traceable identity in a few lines of Python. By the end you'll know when a name-only identity is enough and when you need a signed, verifiable one your identity provider mints.

API Keys vs JWT for AI Agent Tools: Which to Use

The debate over API keys vs JWT for AI agents usually gets strawmanned: a vendor comparison declares static keys "insecure" and pushes you toward tokens you don't need yet. That framing is wrong. For a single internal tool with one caller, a pre-shared API key is a perfectly good, production-grade choice — and Promptise Foundry ships APIKeyAuth as a first-class provider, not a training-wheels fallback. By the end of this article you'll be able to match your actual threat model to the right provider, and know the exact moment JWT and verifiable identity start earning their extra complexity.

Microsoft Entra Agent ID with Promptise Foundry

If your organization already runs on Azure, wiring Entra agent identity into your AI agents is less about adopting something new and more about consuming an identity you can already issue. This post is for teams standardized on Microsoft Entra who want a billing bot, a reporting bot, or any autonomous agent to present a signed, Entra-verified token to the MCP servers it calls — automatically, with no static API keys to leak or rotate. By the end you will know exactly which piece Azure owns, which piece Promptise Foundry owns, and how to get from a managed identity to a verified tool call in one build_agent() call.

Give each AI agent its own identity, not a shared key

Give each AI agent its own identity and "which agent did this?" stops being a guess: instead of threading one shared API key through env for a whole fleet, you attach a distinct AgentIdentity in the build_agent() call, and that identity gets stamped onto every tool call, every LLM turn, and every HMAC-chained audit entry the agent produces. This is a concrete how-to — not another essay about the "identity gap." By the end you'll have two agents that no longer share one credential or one blast radius: a billing bot that can issue refunds and a read-only reporter that can't, each traceable to itself.

How does an AI agent authenticate to an API? (not API keys)

How does an AI agent authenticate to an API without a static, long-lived key you have to babysit? The default answer — mint one API key per agent, paste it into the tool config, and hope it never leaks — is the exact anti-pattern that modern identity abandoned for humans a decade ago. Humans stopped carrying passwords into every system and moved to short-lived, provider-issued tokens; agents, a brand-new class of non-human actor, deserve the same. This pillar walks the real alternative end to end: a short-lived credential minted from the agent's own workload identity, presented to each API automatically, and verified server-side with published keys. No secret to store, rotate, or leak.

JWT Authentication for MCP Servers: Step by Step

JWT authentication for MCP servers is the piece the protocol spec leaves out: it tells you how to move bytes over stdio, HTTP, or SSE, but not how to prove who is calling a tool or stop an unauthorized agent from invoking your delete_all endpoint. If you have shipped a Model Context Protocol server and now need to lock it down, you are in the right place. By the end of this post you will understand the three-layer model Promptise Foundry uses — a JWT provider, AuthMiddleware, and per-tool guards — and you will have a copy-paste server where only the tools you mark are protected.

Pass User Identity Through Agents to MCP Tools

Getting multi-user agent identity right is the difference between a demo and a product your auditors will sign off on. The moment two customers share one agent, you have to answer a hard question: when Alice asks "show my invoices," how does her identity reach the tool server so it returns her data and not Bob's — without the client simply asserting whatever roles it likes? This post traces the whole path in Promptise Foundry: from a per-request CallerContext in your app, to a bearer token on the wire, to server-side JWT extraction and role/tenant guards. By the end you'll be able to wire it end to end and know exactly where the trust boundary sits.

OAuth for AI Agents: client_credentials & JWKS

Most guides to OAuth for AI agents drown you in redirect URLs, consent screens, and PKCE — none of which your agent uses. An autonomous agent is a machine calling another machine. There is no browser, no human clicking "Allow." The grant you actually want is client_credentials: the agent presents a signed token it got from your identity provider, and your server verifies that token against the issuer's public keys. By the end of this post you'll know exactly which OAuth flow agents use, and how to verify agent-presented tokens in a Promptise MCP server with JwksAuth and AsymmetricJWTAuth — no shared secret in sight.

One agent, many APIs: per-resource credentials done right

Getting per-resource credentials for one agent right is the difference between a fleet you can reason about and a drawer full of static tokens you rotate by hand. A real agent rarely talks to one backend. billing-bot reads invoices from a billing MCP server and pulls account details from a CRM API — and each of those resources, if it takes security seriously, demands a token minted for its own audience. The billing server wants an aud of api://billing; the CRM wants api://crm; neither should ever accept the other's token. The naive answer is one static bearer per backend, provisioned and rotated separately, which is exactly where leaks and over-scoping creep in. Promptise Foundry mints a resource-scoped credential per audience from a single AgentIdentity — cached and refreshed independently, and verified server-side with an audience check that blocks a token from being replayed at the wrong resource.

Does the user's identity survive agent delegation?

The honest answer for most agent stacks is: not unless you thread it by hand. To propagate user identity across agent delegation — so that when an orchestrator acting on Alice's behalf hands a subtask to a peer via ask_peer or broadcast, the peer still runs as Alice — you normally have to pass the principal down every hop yourself. Miss it on one call and the peer runs unattributed: its memory search, its semantic cache, its conversation ownership, and its audit trail all detach from the real user. In a multi-tenant product, "unattributed" quietly becomes "cross-tenant," and that is the exact leak a security reviewer will find.

How do you revoke an AI agent's access instantly?

To revoke an AI agent's access the moment it misbehaves, you need a single place to flip — not a scavenger hunt for a leaked string across every service that trusts it. That is exactly what a static per-agent API key can't give you: revoking it means minting a new one, editing every deployment that holds the old value, and redeploying without a gap — all while you may not even be sure which agent leaked it. Back the agent with an identity from your IdP instead, and revocation collapses into one directory operation: disable the identity, and its short-lived, audience-scoped credentials stop validating everywhere, with no server reconfiguration. This post shows the revoke path, why short-lived tokens keep the blast radius small, and how Promptise zero-fills any credential a running agent still holds in memory.

Secure Agent-to-Agent Authentication in Practice

Secure agent-to-agent communication is the part of every multi-agent demo that quietly gets skipped: one agent delegates a task to another, the second agent acts, and when you open the log the only actor recorded is "the assistant." That is not an audit trail — it is a shrug. If a planner agent asks a payments agent to issue a refund, you need to know which agent asked, whether the callee was allowed to trust it, and where that decision landed in a tamper-evident record. By the end of this article you will know how Promptise Foundry propagates a verifiable caller identity through a delegation call and lands the answer to "who delegated to whom" in an HMAC-chained audit log.

Give an AI agent a SPIFFE SVID identity in Kubernetes

A SPIFFE SVID identity for AI agents is the cleanest way to authenticate an autonomous agent inside a service mesh you already run: if your platform uses SPIRE, every workload already receives a short-lived, cryptographic SVID from the Workload API, yet no mainstream agent framework consumes one to prove which agent is acting. This how-to closes that gap. You will wire AgentIdentity.from_spiffe into build_agent, let SPIRE mint a per-audience JWT-SVID for each MCP server the agent calls, and verify those tokens server-side with JwksAuth against your trust domain — with automatic SVID rotation and not one static secret in code or env.

SPIFFE vs Entra vs AWS IAM: pick an agent identity provider

Choosing between SPIFFE vs Entra vs AWS IAM for AI agents is not really a question of which identity provider is best in the abstract — it is a question of which one your platform already issues workload identities from, because that is the one you can back an agent with today. If you have already decided your agents deserve their own verifiable identity instead of a shared key (the case the workload-identity hub makes), this is the follow-up decision: pick the provider. This post is a bake-off across the five Promptise supports — SPIFFE/SPIRE, Microsoft Entra, AWS IAM, Google Cloud, and generic OIDC — compared on the three things that actually differ between them: how the token is acquired, how you revoke it, and when each one fits.

Zero-trust: verify the calling agent, not its name

In a zero-trust agent mesh you must verify the calling agent server-side — cryptographically, on the resource that receives the call — because a self-asserted agent name in a request body is trivial to forge. Agent A tells your billing server "I am billing-bot"; your server believes it; a compromised or misconfigured Agent B says exactly the same thing. If the only thing standing between a caller and issue_refund is a string it chose for itself, you have no security boundary at all — you have a naming convention.

What Is Workload Identity for AI Agents?

Workload identity for AI agents is the practice of giving every agent a stable, verifiable identity of its own — minted by the identity provider you already run — instead of handing the whole fleet one shared API key. If you deploy more than one agent, you have probably already felt the gap: your logs say "the model" did something, your audit trail can't name which agent hit which tool, and every agent holds the same credential so every agent has the same blast radius. By the end of this post you will know exactly what workload identity means for agents, why it is the same problem enterprises solved for services years ago, and how to give your first agent a real identity with no new secrets to manage.