{ "slug": "agent-identity-and-authentication-for-ai-agents", "title": "How AI Agents Prove Identity and Delegated Authority", "description": "The two-layer model an autonomous agent needs to pass before any credential-custody or permission question even applies: a cryptographic workload identity proving what it is (SPIFFE/SPIRE, cloud workload identity federation) and a separate delegated-authority grant proving it may act on a human's or org's behalf (OAuth scopes, RFC 8693 token exchange, RFC 8707 audience binding).", "kind": "sub", "order": 10, "target_query": "how AI agents authenticate and prove delegated authority to act", "secondary_queries": [ "SPIFFE SPIRE workload identity for AI agents", "RFC 8693 OAuth token exchange for agents", "workload identity vs delegated authority for AI agents", "cloud workload identity federation for autonomous agents" ], "tags": [ "agents", "security", "identity", "authentication", "oauth", "spiffe", "workload-identity", "delegation" ], "published": "2026-09-18", "updated": "2026-10-02", "words": 1688, "estimated_tokens": 2245, "premium": false, "rights": { "access": "free", "note": "Editorial guides are always free and never part of the licensed corpus.", "license": "https://changegamer.ai/license.xml", "pricing": "https://changegamer.ai/api/pricing.json", "payment": "https://changegamer.ai/api/payment.json" }, "license": "https://changegamer.ai/license.xml", "citation": "ChangeGamer (2026-09-18). How AI Agents Prove Identity and Delegated Authority. ChangeGamer. https://changegamer.ai/articles/agent-identity-and-authentication-for-ai-agents (updated 2026-10-02).", "bibtex": "@misc{changegamer_agent_identity_and_authentication_for_ai_agents, title = {How AI Agents Prove Identity and Delegated Authority}, publisher = {ChangeGamer}, year = {2026}, url = {https://changegamer.ai/articles/agent-identity-and-authentication-for-ai-agents}, note = {Updated 2026-10-02}}", "canonical": "https://changegamer.ai/articles/agent-identity-and-authentication-for-ai-agents", "markdown": "https://changegamer.ai/articles/agent-identity-and-authentication-for-ai-agents.md", "takeaways": [ "An autonomous agent has to establish two separate things before any custody or permission question applies: a cryptographic workload identity proving what it is, and a distinct delegated-authority grant proving it may act on a human's or organization's behalf.", "SPIFFE and SPIRE, which graduated from CNCF incubation in September 2022, issue each running workload a short-lived SVID that the SPIRE server only mints after checking platform-level launch evidence, replacing a static key nobody can tie to one running process.", "An agent that simply holds and forwards a user's own OAuth token creates a confused-deputy vulnerability, because the downstream service receiving that token cannot tell a legitimate agent request from a forged one.", "RFC 8693 token exchange lets an agent trade a token it already holds for a narrower one scoped to a specific sub-task, and RFC 8707 resource-indicator audience binding stops that narrower token from being replayed against a service it was never issued for.", "The IETF WIMSE working group, chartered at IETF 119 in March 2024, and the OpenID Foundation's October 2025 agentic-AI identity whitepaper are both active standardization efforts rather than settled specifications as of June 2026, so treat agent-specific identity claims in OIDC tokens as an emerging direction, not an adopted standard." ], "outline": [ { "depth": 2, "text": "What does an AI agent actually have to prove before it acts?", "anchor": "what-does-an-ai-agent-actually-have-to-prove-before-it-acts", "url": "https://changegamer.ai/articles/agent-identity-and-authentication-for-ai-agents#what-does-an-ai-agent-actually-have-to-prove-before-it-acts" }, { "depth": 2, "text": "How does an agent prove what it is?", "anchor": "how-does-an-agent-prove-what-it-is", "url": "https://changegamer.ai/articles/agent-identity-and-authentication-for-ai-agents#how-does-an-agent-prove-what-it-is" }, { "depth": 2, "text": "How does an agent prove it has permission to act for a human or org?", "anchor": "how-does-an-agent-prove-it-has-permission-to-act-for-a-human-or-org", "url": "https://changegamer.ai/articles/agent-identity-and-authentication-for-ai-agents#how-does-an-agent-prove-it-has-permission-to-act-for-a-human-or-org" }, { "depth": 2, "text": "What closes the confused-deputy gap between two agents or services?", "anchor": "what-closes-the-confused-deputy-gap-between-two-agents-or-services", "url": "https://changegamer.ai/articles/agent-identity-and-authentication-for-ai-agents#what-closes-the-confused-deputy-gap-between-two-agents-or-services" }, { "depth": 2, "text": "What standards are still emerging for agent-specific identity?", "anchor": "what-standards-are-still-emerging-for-agent-specific-identity", "url": "https://changegamer.ai/articles/agent-identity-and-authentication-for-ai-agents#what-standards-are-still-emerging-for-agent-specific-identity" }, { "depth": 2, "text": "Where does this identity layer stop, and custody or enforcement begin?", "anchor": "where-does-this-identity-layer-stop-and-custody-or-enforcement-begin", "url": "https://changegamer.ai/articles/agent-identity-and-authentication-for-ai-agents#where-does-this-identity-layer-stop-and-custody-or-enforcement-begin" }, { "depth": 2, "text": "An identity and delegated-authority checklist", "anchor": "an-identity-and-delegated-authority-checklist", "url": "https://changegamer.ai/articles/agent-identity-and-authentication-for-ai-agents#an-identity-and-delegated-authority-checklist" } ], "faq": [ { "question": "What two things does an AI agent need to prove before it can act?", "answer": "An AI agent needs to prove two distinct things before it acts: a cryptographic workload identity establishing what the running agent itself is, independent of any user, and a separate delegated-authority grant establishing that a specific human or organization has authorized it to act on their behalf — conflating these two layers is the root cause of most agent-authentication mistakes." }, { "question": "Why is a static API key a poor way to identify an AI agent workload?", "answer": "A static API key shared across agent instances cannot be pinned to one specific running process, does not rotate automatically, and grants an attacker indefinite access the moment it leaks, which is why short-lived, cryptographically attested credentials such as SPIFFE/SPIRE's SVIDs — issued only after platform-level launch evidence is checked — are the workload-identity mechanism built to replace it." }, { "question": "Why is it risky for an agent to hold and forward a user's own access token?", "answer": "Forwarding a user's own access token is risky because that token usually carries broader scopes than the agent's current task needs, gives the agent no distinct audit identity separate from the human it acted for, and creates a confused-deputy vulnerability where a downstream service cannot tell a legitimate forwarded request from a forged one — RFC 8693 token exchange exists specifically to let an agent trade that token for a narrower one instead." }, { "question": "What does RFC 8707 audience binding actually stop an attacker from doing?", "answer": "RFC 8707 resource-indicator audience binding adds a resource parameter to an OAuth request so the issued token's audience claim is tied to one specific resource server, which stops a token issued for one service from being replayed against a different service it was never meant to reach — closing the specific reuse path that plain token forwarding leaves open." }, { "question": "Is SPIFFE/SPIRE a finished, universally adopted standard for agent identity as of 2026?", "answer": "SPIFFE and SPIRE are a mature, widely adopted CNCF-graduated standard (graduated September 2022) for workload identity generally, but the newer WIT-SVID profile that binds a SPIFFE credential to the workload's own key pair sits at \"Incubating\" stability as of mid-2026, below the framework's \"Stable\" tier, so treat that specific extension as still settling rather than as finished." } ], "body": "## What does an AI agent actually have to prove before it acts?\n\nAn AI agent has to prove two separate things before any downstream credential-custody or permission question even applies: what it *is*, as a running piece of software with its own cryptographic identity, and separately, that it holds *delegated authority* to act on behalf of a specific human or organization. The [agent identity and authentication](/resources/agent-identity-authentication) reference (updated 17 July 2026) frames this directly as a two-layer model, and calls conflating the two layers the root cause of most agent-auth mistakes — a system that only checks one of the two is checking half the question. This sub sits inside the [agent security operations](/articles/agent-security-operations) pillar's eight-discipline stack as the identity layer underneath its credential-hygiene discipline.\n\nThis is deliberately upstream of two other questions this cluster answers elsewhere. [Managing secrets for AI agents](/articles/credential-hygiene-for-ai-agents) covers who holds a credential once one already exists, across a chain of tool servers and MCP connectors — custody. [Enforcing permission boundaries at runtime](/articles/permission-boundaries-and-least-privilege-for-ai-agents) covers what an already-authenticated caller is allowed to do on any given call, checked at eight runtime checkpoints — enforcement. Neither question has an answer until identity and delegated authority are established first: a policy engine cannot enforce a boundary for a caller it cannot identify, and a credential inventory means nothing if the thing holding the credential was never proven to be what it claims.\n\n## How does an agent prove what it is?\n\nAn agent proves what it is through a cryptographically attested, short-lived credential issued to the specific running workload — the software analogue of a TLS server certificate, minted dynamically rather than baked in as a static secret. A shared key copied across every instance of an agent fleet cannot answer \"which process is this\" at all: it does not rotate on its own, it cannot be pinned to one running workload, and a single leak hands out access with no expiry.\n\n**SPIFFE/SPIRE** (Secure Production Identity Framework for Everyone) is the most widely adopted open standard for this layer, having graduated from CNCF incubation in September 2022. SPIRE issues each workload a SPIFFE Verifiable Identity Document, or SVID, only after its server checks platform-level launch evidence — a Kubernetes service account token, an AWS instance identity document, a GCP metadata service token — so the credential is tied to a workload SPIRE has actually watched come up, not to a string anyone could copy. Three SVID forms exist:\n\n- **X.509-SVID** — a certificate carrying the workload's SPIFFE ID as a URI in its Subject Alternative Name field, used directly for mutual TLS between two workloads.\n- **JWT-SVID** — a signed JWT carrying the same SPIFFE ID, presented as a bearer token in an Authorization header for HTTP/REST contexts.\n- **WIT-SVID** — a newer SPIFFE profile of the IETF WIMSE working group's Workload Identity Token format, added at \"Incubating\" stability as of mid-2026; unlike JWT-SVID it binds the token to the workload's own key pair via a `cnf` claim, so possession alone isn't enough to use it.\n\nSVIDs rotate automatically through the SPIRE agent, with no human re-issuing anything on a schedule. The same short-lived-credential logic extends across cloud boundaries through **workload identity federation**: a workload trades the OIDC token its home platform already issued it for temporary credentials in a different cloud, via a security token service, with no static cross-cloud secret ever shared. GCP Workload Identity Federation, AWS IAM Roles Anywhere, and Azure Managed Identities are the three major implementations of that pattern.\n\n## How does an agent prove it has permission to act for a human or org?\n\nAn agent proves delegated authority through a scoped authorization grant — separate from its own workload identity — that a human or organization issued for a bounded purpose, not by holding that human's own credentials. OAuth 2.0 authorization code flow with scopes is the standard mechanism: a user authorizes a specific set of scopes, and the agent receives a token limited to exactly those operations, ideally requested narrowly for the task at hand rather than broadly for every task the agent might ever run.\n\nThe failure mode the resource names explicitly is an agent that simply stores and forwards the user's own access or refresh token instead. That token typically carries scopes far wider than the current task, gives the agent no audit identity distinct from the human it is acting for, and — if it leaks — grants an attacker everything the user themselves could do. Worse, an agent that receives a user's token from an orchestrator and passes it straight through to a downstream service creates a confused-deputy vulnerability: the receiving service has no way to distinguish a legitimate request routed through the agent from a forged one, because the token's audience was never validated against who is actually presenting it.\n\n## What closes the confused-deputy gap between two agents or services?\n\nTwo IETF mechanisms close it together, and neither one alone is sufficient. **RFC 8693 (OAuth 2.0 Token Exchange, January 2020)** defines a grant type — `urn:ietf:params:oauth:grant-type:token-exchange` — for an agent to present a token it already holds and receive a different, narrower one scoped to a specific downstream sub-task, instead of forwarding its original broad token further down the chain. **RFC 8707 (Resource Indicators for OAuth 2.0, February 2020)** adds a `resource` parameter to the request so the authorization server binds the issued token's audience claim to one named resource server, which is what actually stops a token minted for Service A from being replayed against Service B. How those two mechanisms compose across several agent-to-agent hops, including the `act` and `may_act` claims, is covered in [agent delegation chains](/resources/agent-delegation-chains).\n\nUsed together, the two form the general-purpose fix for the token-passthrough anti-pattern above: exchange, rather than forward, and bind the exchanged token's audience to exactly the service it is headed for. MCP's own authorization spec applies this same logic at the protocol level by forbidding token passthrough outright — the wire-level mechanics of that specific flow, including PKCE and MCP's own audience-binding requirements, belong to [implementing OAuth 2.1 for an MCP server](/articles/mcp-oauth-implementation) rather than this general identity layer.\n\n## What standards are still emerging for agent-specific identity?\n\nAs of June 2026, two efforts are actively closing agent-specific gaps that existing identity and OAuth standards weren't written to cover, and neither is a finished, adopted standard yet. **IETF WIMSE** (Workload Identity in Multi-System Environments), chartered at IETF 119 in March 2024, is producing architecture documents and token-exchange profiles for a workload that must authenticate across heterogeneous platforms and hand off a credential to a downstream system using a different identity scheme than its own. **The OpenID Foundation's AI Identity Management Community Group** published a whitepaper in October 2025 identifying the same two-layer split this article covers — the agent software authenticated as a trusted client, and the human delegating specific permissions — as two layers that must work in tandem rather than get collapsed into one. Individual Internet-Drafts have followed, such as draft-sharif-openid-agent-identity-00 (March 2026), proposing agent-specific claims for OpenID Connect ID tokens covering ownership, trust posture, and authorized capabilities; these carry no formal IETF working-group standing as of June 2026 and should be read as a direction the identity community is exploring, not a mechanism to build production auth on top of today.\n\n## Where does this identity layer stop, and custody or enforcement begin?\n\nIdentity and delegated-authority verification end the moment a caller has been proven to be a specific workload and shown to hold a valid grant — everything past that point is a different question this cluster answers elsewhere. A tool server, MCP connector, or plugin that sits between an already-identified agent and the resource it is calling raises a custody question next: which system actually holds the resulting credential, and does that intermediary have its own separate, longer-lived token an attacker could target instead? That custody question, and the audit steps for answering it across a multi-hop chain, is [managing secrets for AI agents](/articles/credential-hygiene-for-ai-agents)'s territory, not this one.\n\nA per-call authorization question follows after that: given that an agent has already been identified and its delegated-authority grant established, what is it allowed to do on this specific call? A policy dispatcher answers that by checking a live snapshot against a manifest at each step of an agent's execution loop — covered in [enforcing permission boundaries for AI agents at runtime](/articles/permission-boundaries-and-least-privilege-for-ai-agents). None of that enforcement logic can run meaningfully against a caller whose identity and authority were never established in the first place, which is exactly why this layer has to come first.\n\n## An identity and delegated-authority checklist\n\nA deployment has covered this layer once each item below is true, independent of the credential-custody and runtime-enforcement checklists this cluster covers separately:\n\n- Every running agent instance carries its own cryptographically attested workload credential — an SVID or equivalent — rather than a static key it shares with the rest of its fleet\n- Cross-cloud calls trade a home-platform OIDC token for short-lived target-cloud credentials through a security token service, with no static secret shared between the two environments\n- Delegated-authority grants are scoped OAuth tokens requested for the task at hand, never the user's own raw access or refresh token stored inside the agent\n- A downstream hop exchanges its incoming token for a narrower one via RFC 8693 rather than forwarding the original token further down the chain\n- Every issued token carries an RFC 8707 audience binding naming the one resource server it is valid for, so a captured token can't be replayed elsewhere\n- WIMSE and OpenID Foundation agent-identity proposals are tracked as an emerging direction worth monitoring, not treated as settled enough to build a production identity layer on alone\n\nGet this layer right and the two questions built on top of it — who holds a credential across a chain, and what an already-authenticated caller may do on a given call — finally have a stable caller identity to attach their own answers to. Skip it, and a credential inventory or a runtime policy engine is enforcing rules against a caller nobody actually verified.", "cluster": { "id": "agent-security-operations", "title": "Agent security operations", "description": "How to defend an AI agent deployment from the operator side — secrets and credential hygiene, prompt-injection defense in depth, sandboxing, supply-chain provenance, least privilege, audit trails, incident response, and rate/abuse controls — not buyer-side fraud and not reliability-framed guardrails.", "status": "complete", "pillar": { "slug": "agent-security-operations", "title": "How to Secure AI Agents in Production", "description": "Credential hygiene, prompt-injection defense in depth, sandboxing choices for code execution, supply-chain provenance, least privilege, audit trails, incident response, and rate/abuse controls — eight operator-side defenses against an adversarial actor or a compromised dependency, not against ordinary load or failure.", "kind": "pillar", "order": 0, "html": "https://changegamer.ai/articles/agent-security-operations", "markdown": "https://changegamer.ai/articles/agent-security-operations.md", "json": "https://changegamer.ai/api/articles/agent-security-operations.json" }, "articles": [ { "slug": "credential-hygiene-for-ai-agents", "title": "How to Manage Secrets for AI Agents in Production", "description": "Why single-agent credential issuance is not the whole secrets problem: auditing which tool servers and MCP connectors hold credentials on an agent's behalf, treating provider-side prompt caches as a disclosure surface, and the named frameworks — OWASP's Secrets Management Cheat Sheet, Twelve-Factor config, and the OWASP GenAI project — that govern the rest.", "kind": "sub", "order": 1, "html": "https://changegamer.ai/articles/credential-hygiene-for-ai-agents", "markdown": "https://changegamer.ai/articles/credential-hygiene-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/credential-hygiene-for-ai-agents.json" }, { "slug": "prompt-injection-defense-in-depth-for-agents", "title": "How to Defend an AI Agent Against Prompt Injection", "description": "A decision framework for matching Action-Selector, Plan-Then-Execute, Dual LLM, and the other named architectural patterns to a task's actual blast radius, including when to compose two patterns together and when none of them is worth the overhead.", "kind": "sub", "order": 2, "html": "https://changegamer.ai/articles/prompt-injection-defense-in-depth-for-agents", "markdown": "https://changegamer.ai/articles/prompt-injection-defense-in-depth-for-agents.md", "json": "https://changegamer.ai/api/articles/prompt-injection-defense-in-depth-for-agents.json" }, { "slug": "choosing-a-sandbox-for-ai-agent-code-execution", "title": "How to Choose a Sandbox for AI Agent Code Execution", "description": "A two-axis framework — trust in the code's source crossed with the blast radius of a successful escape — for picking an isolation layer, choosing among six hosted sandbox APIs, and hardening the harness around whichever one you pick.", "kind": "sub", "order": 3, "html": "https://changegamer.ai/articles/choosing-a-sandbox-for-ai-agent-code-execution", "markdown": "https://changegamer.ai/articles/choosing-a-sandbox-for-ai-agent-code-execution.md", "json": "https://changegamer.ai/api/articles/choosing-a-sandbox-for-ai-agent-code-execution.json" }, { "slug": "supply-chain-provenance-for-ai-agents", "title": "How to Verify Supply-Chain Provenance for AI Agent Dependencies", "description": "An operational playbook for three separate trust-boundary gates — package-install time, model-load time, and MCP-server-connect time — that turns SBOM and attestation formats into checks a pipeline can actually run, plus a fail-closed default for the dependency that carries neither.", "kind": "sub", "order": 4, "html": "https://changegamer.ai/articles/supply-chain-provenance-for-ai-agents", "markdown": "https://changegamer.ai/articles/supply-chain-provenance-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/supply-chain-provenance-for-ai-agents.json" }, { "slug": "permission-boundaries-and-least-privilege-for-ai-agents", "title": "How to Enforce Permission Boundaries for AI Agents at Runtime", "description": "How a least-privilege grant actually gets enforced once an agent is running — the eight named checkpoints, five verdicts, and fail-closed contract in Microsoft's draft Agent Control Specification (ACS), and what happens when the policy engine that enforces the boundary breaks.", "kind": "sub", "order": 5, "html": "https://changegamer.ai/articles/permission-boundaries-and-least-privilege-for-ai-agents", "markdown": "https://changegamer.ai/articles/permission-boundaries-and-least-privilege-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/permission-boundaries-and-least-privilege-for-ai-agents.json" }, { "slug": "audit-trails-for-ai-agents", "title": "How to Build an Audit Trail for an AI Agent", "description": "A field-by-field forensic playbook for an AI agent audit log: why each of the checklist's seven required fields matters for reconstruction, a worked incident walkthrough, and the real tension between OpenTelemetry's redact-by-default tracing and full audit logging.", "kind": "sub", "order": 6, "html": "https://changegamer.ai/articles/audit-trails-for-ai-agents", "markdown": "https://changegamer.ai/articles/audit-trails-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/audit-trails-for-ai-agents.json" }, { "slug": "security-incident-response-for-ai-agents", "title": "How to Respond When an AI Agent Takes a Harmful Action", "description": "Why the pillar's cut-credential, stop-instance, export-evidence order is structurally forced rather than a tidy convention, a concrete answer for who holds standing revocation authority, a pre-incident drill for the evidence-export path, and what changes when the compromised credential belongs to a third-party tool server instead of the agent itself.", "kind": "sub", "order": 7, "html": "https://changegamer.ai/articles/security-incident-response-for-ai-agents", "markdown": "https://changegamer.ai/articles/security-incident-response-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/security-incident-response-for-ai-agents.json" }, { "slug": "rate-and-abuse-controls-for-ai-agents", "title": "How to Rate-Limit and Cap Spend for Your Own AI Agent", "description": "Enforcement mechanics for the two ceilings an agent operator should set before production: where a per-credential tool-call counter has to live to stay correct under concurrent calls, where a spend ceiling gets checked in the tool-call loop, and how to reject out-of-scope tool-call arguments with canonicalization rather than a naive prefix match.", "kind": "sub", "order": 8, "html": "https://changegamer.ai/articles/rate-and-abuse-controls-for-ai-agents", "markdown": "https://changegamer.ai/articles/rate-and-abuse-controls-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/rate-and-abuse-controls-for-ai-agents.json" }, { "slug": "content-provenance-for-ai-agents", "title": "How to Verify Content Provenance for AI Agents with C2PA", "description": "A three-state decision procedure — valid manifest, invalid signature, absent manifest — for what an AI agent's ingestion pipeline should do differently with a web image, an email attachment, or a retrieved document, plus a checklist for wiring a C2PA reader library into that pipeline as a gate before content reaches the model.", "kind": "sub", "order": 9, "html": "https://changegamer.ai/articles/content-provenance-for-ai-agents", "markdown": "https://changegamer.ai/articles/content-provenance-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/content-provenance-for-ai-agents.json" }, { "slug": "agent-identity-and-authentication-for-ai-agents", "title": "How AI Agents Prove Identity and Delegated Authority", "description": "The two-layer model an autonomous agent needs to pass before any credential-custody or permission question even applies: a cryptographic workload identity proving what it is (SPIFFE/SPIRE, cloud workload identity federation) and a separate delegated-authority grant proving it may act on a human's or org's behalf (OAuth scopes, RFC 8693 token exchange, RFC 8707 audience binding).", "kind": "sub", "order": 10, "html": "https://changegamer.ai/articles/agent-identity-and-authentication-for-ai-agents", "markdown": "https://changegamer.ai/articles/agent-identity-and-authentication-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/agent-identity-and-authentication-for-ai-agents.json" }, { "slug": "data-privacy-and-pii-for-ai-agents", "title": "How to Protect PII and Personal Data in AI Agent Pipelines", "description": "Why an AI agent expands PII exposure past a bounded API call — large ingested context, external tool calls, persistent memory and logs, provider training risk — and the containment controls, provider data-handling terms, and GDPR/EU AI Act/CCPA compliance boundary that follow from it.", "kind": "sub", "order": 11, "html": "https://changegamer.ai/articles/data-privacy-and-pii-for-ai-agents", "markdown": "https://changegamer.ai/articles/data-privacy-and-pii-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/data-privacy-and-pii-for-ai-agents.json" }, { "slug": "agent-security-operations-checklist", "title": "The AI Agent Security Checklist", "description": "A go/no-go checklist that turns the agent security operations pillar's eight disciplines, plus content provenance, agent identity, and data privacy, into checkable gates — the specific inventory row, test result, or logged decision that proves each one holds, with a link to whichever sibling article owns its mechanics.", "kind": "sub", "order": 12, "html": "https://changegamer.ai/articles/agent-security-operations-checklist", "markdown": "https://changegamer.ai/articles/agent-security-operations-checklist.md", "json": "https://changegamer.ai/api/articles/agent-security-operations-checklist.json" } ] }, "navigation": { "pillar": { "slug": "agent-security-operations", "title": "How to Secure AI Agents in Production", "description": "Credential hygiene, prompt-injection defense in depth, sandboxing choices for code execution, supply-chain provenance, least privilege, audit trails, incident response, and rate/abuse controls — eight operator-side defenses against an adversarial actor or a compromised dependency, not against ordinary load or failure.", "kind": "pillar", "order": 0, "html": "https://changegamer.ai/articles/agent-security-operations", "markdown": "https://changegamer.ai/articles/agent-security-operations.md", "json": "https://changegamer.ai/api/articles/agent-security-operations.json" }, "previous": { "slug": "content-provenance-for-ai-agents", "title": "How to Verify Content Provenance for AI Agents with C2PA", "description": "A three-state decision procedure — valid manifest, invalid signature, absent manifest — for what an AI agent's ingestion pipeline should do differently with a web image, an email attachment, or a retrieved document, plus a checklist for wiring a C2PA reader library into that pipeline as a gate before content reaches the model.", "kind": "sub", "order": 9, "html": "https://changegamer.ai/articles/content-provenance-for-ai-agents", "markdown": "https://changegamer.ai/articles/content-provenance-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/content-provenance-for-ai-agents.json" }, "next": { "slug": "data-privacy-and-pii-for-ai-agents", "title": "How to Protect PII and Personal Data in AI Agent Pipelines", "description": "Why an AI agent expands PII exposure past a bounded API call — large ingested context, external tool calls, persistent memory and logs, provider training risk — and the containment controls, provider data-handling terms, and GDPR/EU AI Act/CCPA compliance boundary that follow from it.", "kind": "sub", "order": 11, "html": "https://changegamer.ai/articles/data-privacy-and-pii-for-ai-agents", "markdown": "https://changegamer.ai/articles/data-privacy-and-pii-for-ai-agents.md", "json": "https://changegamer.ai/api/articles/data-privacy-and-pii-for-ai-agents.json" } }, "resources": [ { "slug": "agent-identity-authentication", "html": "https://changegamer.ai/resources/agent-identity-authentication", "markdown": "https://changegamer.ai/resources/agent-identity-authentication.md", "json": "https://changegamer.ai/api/resources/agent-identity-authentication.json" } ] }