> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity.md). # 1.5 Agent and non-human identity How to give AI agents scoped, attributable identities instead of borrowed human credentials. *Last reviewed: August 18, 2026* {% hint style="info" %} Agents need attributable identities. A task that reads files, calls tools, writes tickets, opens pull requests, or uses an API should leave a record of the human sponsor, the agent or workload identity, and the system it acted through. {% endhint %} ## Agent and non-human identity: what security teams need to know AI agents blur a line that security teams usually rely on. A person starts the work, but the agent may plan steps, call tools, run code, read files, write to services, and continue after the first prompt. If every action is recorded only as the human user, investigations become guesswork. If the agent uses a shared API key, they become harder. Non-human identity gives the agent or workload its own scoped identity. That identity might be a service account, an access token minted through workload identity federation, a gateway-issued token, a CI identity, or an internal service principal. The format matters less than the control goal: the identity should be scoped, attributable, revocable, logged, and separate from a person's normal interactive account. The best design keeps two facts together. First, who initiated or approved the run. Second, which non-human identity executed each action. When those facts split apart, access reviews and incident response get thin. ## Common agent and non-human identity security failures * Agents use a developer's personal API key in CI or production. * Several agents share the same service account, making activity attribution weak. * A service account can access every project because it was created once and reused. * Logs show an API key or bot user, but not the human sponsor, approval, or business owner. * Agent-owned connections persist after the agent is retired. * Tool calls inherit a human user's broad SaaS permissions when a narrower delegated identity would be safer. ## Agent and non-human identity security controls checklist * Assign each production agent or workload a named owner. * Use per-agent or per-workload identities where the platform supports them. * Separate production, staging, and test identities. * Scope each identity to the minimum projects, models, tools, connectors, and data classes it needs. * Prefer short-lived credentials issued through workload identity federation or a gateway for automated workloads. * Log the initiating user, approving user where applicable, workload identity, tool call, target system, and outcome. * Review service accounts, token mappings, and connected app grants on a fixed cadence. * Revoke or disable identities when an agent is retired, paused, or moved to a new owner. ## Anthropic ### Overview Claude Code supports several authentication paths, including Claude.ai credentials, Claude Console credentials, cloud provider credentials, gateway-issued tokens, API keys, bearer tokens, dynamic credential helper scripts, and OAuth tokens for non-browser contexts. The credential precedence matters because an environment variable can override the expected interactive account path once approved. Anthropic's Claude Code security documentation also describes scoped credentials in cloud execution and audit logging for cloud sessions. For local and CI usage, organizations should decide whether credentials come from a user login, an API key, a gateway, a cloud provider identity, or a dynamic helper that pulls short-lived credentials. Claude Managed Agents extend the picture to hosted, long-running agents. Managed Agents support vault-based authentication for credentials, and scheduled deployments run recurring agent work without a person present, so treat each deployment as an unattended identity with an owner, scoped credentials, logging, and a review cadence. Managed Agents is in beta, and sessions persist state server-side and are not currently eligible for zero data retention or HIPAA BAA coverage, so decide which identities and data classes are allowed to use it. Cowork scheduled tasks remain user-owned, but they can keep acting after the initiating conversation. Remote tasks use connected services in the user's workspace context; tasks that need local folders or applications depend on the desktop session. Inventory the human sponsor, schedule, connected identities, local device dependency, and revocation path even when the product does not issue a separate agent identity. Claude Tag has two identity modes that must not be collapsed. In Slack channels it acts through organization-provisioned service accounts and channel-scoped Access bundles, so every channel member can use the same connected authority. In a direct message it uses the requester's Claude account and personal connectors. Inventory those paths separately and correlate channel actions with the Slack thread and the dedicated account shown in the target system. ### Anthropic documentation * [Claude Code authentication](https://code.claude.com/docs/en/team) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Console roles and permissions](https://support.claude.com/en/articles/10186004-claude-console-roles-and-permissions) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Scheduled deployments](https://platform.claude.com/docs/en/managed-agents/scheduled-deployments) * [Schedule recurring tasks in Claude Cowork](https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork) * [How Claude Tag agent identity works](https://claude.com/docs/claude-tag/concepts/agent-identity) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) ## OpenAI ### Overview OpenAI documents workload identity federation for API workloads. Trusted workloads can exchange external OIDC identity tokens for short-lived OpenAI access tokens, and service account mappings can bind specific external token attributes to an OpenAI service account in a project. OpenAI also recommends dedicated service accounts, environment separation, exact claim matching, minimum permissions, regular mapping review, and monitoring token exchange failures or unexpected access patterns. Those recommendations map cleanly to agent identity design. OpenAI Workspace Agents add another non-human credential class. External systems trigger published workspace agents using access tokens that are distinct from platform API keys and Compliance API credentials, so inventory those tokens separately with their own owner, scope, and rotation records. For Codex, OpenAI's governance documentation distinguishes ChatGPT-authenticated Codex activity from API-key-authenticated Codex usage. That distinction matters for audit planning. ChatGPT Work and scheduled tasks are usually delegated user activity rather than standalone service identities. Record the user sponsor, schedule or trigger, plugins and connected apps, local project or cloud execution path, and stop or revoke procedure. Do not let the absence of a new API key keep an unattended task out of the non-human identity inventory. ### OpenAI documentation * [Workload identity federation](https://developers.openai.com/api/docs/guides/workload-identity-federation) * [Workspace Agents](https://developers.openai.com/workspace-agents) * [Codex Governance](https://developers.openai.com/codex/enterprise/governance) * [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275) * [Scheduled tasks](https://learn.chatgpt.com/docs/automations) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about agent and non-human identity ### Should an agent act as the user who launched it? Sometimes, especially for a short interactive task where user consent and user permissions are central. For production or scheduled work, a scoped workload identity is usually easier to review and revoke. ### What is the minimum audit trail? Capture the human sponsor, agent or workload identity, credential source, tool called, target system, timestamp, and result. For write actions, capture the approval path and the external object changed. Keeping the sponsor and the executing identity connected in the same record is what lets an investigator see who started the work and which identity acted. ### When is a shared service account acceptable? Use one only for low-risk experiments or tightly bounded internal tools. For production work, shared identities make cleanup and investigations harder. ### What is non-human identity in AI security? Non-human identity is the account, token, service account, workload identity, or gateway-issued credential an agent or automated system uses when it acts without a person typing each step. ### What should happen when an agent is retired? Revoke or disable its identity, tokens, and service-account mappings, and remove agent-owned connections in downstream systems. Reassign or close out the owner record, then confirm in logs that the identity stops appearing after the retirement date. Scheduled or recurring deployments deserve special attention because they keep running until someone turns them off. ## Applicable regulations and frameworks | Governance page | Relationship to this article | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | G.1 Map your controls to NIST AI RMF and CSF 2.0 | This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports identity and access control. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Access Controls guidance. | | G.6 Write an AI Acceptable Use Policy that holds up | This article supplies a technical or process control used to enforce the acceptable-use policy. | | G.7 Ownership and RACI for AI security | This control depends on the ownership and evidence responsibilities defined in the RACI. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA identity, authentication, least privilege, and workforce access. | *G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.* ## Related handbook guidance * [1. Identity & Access](/handbook/1.-identity-and-access.md) * [1.6 API keys and service accounts governance](/handbook/1.-identity-and-access/1.6-api-keys-and-service-accounts-governance.md) * [1.7 Human-in-the-loop and approval policies](/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies.md) * [5.4 Agent-specific threats: tool poisoning and confused deputy](/handbook/5.-threats-and-adversarial/5.4-agent-specific-threats-tool-poisoning-and-confused-deputy.md) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.harmonic.security/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.