Non-Human Identity (NHI) Governance & Service Account Classification

Access through Non-Human Identity (NHI) occurs when a synthetic subject authenticates or acts using a machine, service, workload, application, or agent identity rather than a direct human login. This may include service accounts, application credentials, OAuth tokens, Application Programming Interface (API) keys, cloud roles, connector credentials, or Model Context Protocol (MCP) server secrets.

This configuration creates an elevated exposure condition because the synthetic subject’s practical capability is defined by the identity and credentials assigned to it. If those credentials are shared, long-lived, over-scoped, or poorly inventoried, the synthetic subject may gain standing access that is difficult to attribute, revoke, or monitor.

The primary risk is unmanaged authority. A synthetic subject may retrieve data, call tools, send messages, update records, or perform workflow actions through credentials that exceed its intended purpose. Where multiple agents share one service account or hard-coded secret, investigators may be unable to determine which synthetic subject acted, which workflow invoked it, or which system granted the access.

Investigators should review the synthetic subject’s assigned identities, credential storage, token lifetime, scopes, authentication logs, service account ownership, vault records, repository secrets, configuration files, and access review history. Particular attention should be given to shared service accounts, orphaned tokens, hard-coded secrets, dormant credentials, privileged scopes, and identities not represented in asset or identity governance inventories.

Investigative Relevance

Access through Non-Human Identity is relevant because identity configuration determines what a synthetic subject can access and perform. Weak NHI configuration may turn a limited assistant, embedded feature, or agent into a privileged actor with access beyond its operational purpose.

Access through human identity occurs when a synthetic subject is configured to use a human employee’s account, session, token, credentials, browser profile, or delegated permissions to access systems or perform actions. This may occur where an employee connects an artificial intelligence tool to their mailbox, browser, source repository, cloud console, productivity suite, or business application using their own identity.

This configuration creates an elevated exposure condition because the synthetic subject inherits the employee’s access, trust, and attribution trail. Actions taken by the synthetic subject may appear in logs as ordinary human activity, even where the employee did not review each action or understand how the synthetic subject used their access.

The primary risk is identity inheritance. The synthetic subject may retrieve data, send messages, modify records, run commands, or trigger workflows using permissions granted to the human account. This makes it difficult to distinguish direct employee behavior from AI-mediated action.

Investigators should review authentication sessions, OAuth grants, connected applications, browser extensions, delegated permissions, endpoint activity, application logs, prompt and response records, tool-call logs, and user activity timelines. Particular attention should be given to AI tools operating inside authenticated user sessions, personal automation scripts, browser agents, local coding assistants, and third-party AI services connected through employee-granted access.

Investigative Relevance

Access through human identity is relevant because it defines what a synthetic subject can do by borrowing the reach of a human account. This weakens identity-based investigation, access governance, and containment because disabling or restricting the synthetic subject may require examining the employee’s sessions, devices, integrations, and delegated grants.

An orchestrated AI system is a deployment pattern where multiple synthetic subjects coordinate to complete a goal. This may involve an orchestrator that decomposes work and delegates tasks to worker agents, or peer agents that call each other across services, teams, or organizations.

This deployment pattern creates an elevated exposure condition because agents may share context, instructions, tools, credentials, or outputs over trusted internal channels. The effective synthetic subject is the whole agent graph, not only the individual agent that performs the final action.

The primary risk is distributed authority. One manipulated agent, poisoned input, or unsafe delegation may spread across the system and cause other agents to act on untrusted instructions. Because agents may treat each other’s outputs as trusted, a single injected instruction can propagate through the graph and influence tool-equipped workers.

A related risk is diffuse attribution. Actions may appear in logs as “the system,” an orchestrator identity, a shared service account, or the final worker agent, rather than the agent or input that originated the decision. This can make intent, origin, data movement, and responsibility difficult to reconstruct after an adverse outcome.

Investigators should review the system directive, orchestration logic, delegation graph, agent identities, inter-agent messages, shared context, tool access, credentials, provenance records, and cross-boundary data flows. Particular attention should be given to new agent-to-agent paths, repeated instructions appearing across agents, aggregate access that exceeds the task scope, and actions that cannot be traced to an approved source.

Investigative Relevance

Orchestrated AI systems are relevant because they allow synthetic subjects to behave like a coordinated internal team. Their combined reach may exceed the access, autonomy, and speed of any individual agent.

This section is especially relevant where orchestrators delegate to tool-equipped workers, agents share context or service identities, agent-to-agent links cross teams or trust zones, or a single workflow can touch multiple systems, data classes, or organizations.

Identity misattribution and impersonation harm occurs when a synthetic subject acts under, imitates, or is confused with a human, service, agent, or organizational identity in a way that deceives people, systems, or records about who is acting. The harm may arise from spoofed identity, shared service accounts, synthetic media, weak agent attribution, or machine identities that are not clearly distinguishable from human users.

This adverse outcome creates organizational harm because identity is used to assign authority, trust, responsibility, and accountability. If a synthetic subject appears to be an employee, executive, service account, approved agent, vendor, or peer system, its actions or messages may be accepted as legitimate even when they are unauthorized, misleading, or harmful.

The primary harm is loss of trustworthy attribution. A synthetic subject may send communications, approve actions, access records, call tools, or modify systems under an identity that does not accurately represent the actor. This can mislead recipients, distort audit trails, weaken contractual trust, and make it difficult to determine whether a human, agent, service, or attacker-controlled identity caused the action.

A related harm is reputational and relationship damage. Third parties may rely on a synthetic message, synthetic voice, synthetic video, or agent-originated action as if it came from a trusted person or system. The organization may then face disputes, fraud loss, customer distrust, regulatory scrutiny, or operational breakdown because identity provenance was unclear or false.

Investigators should review identity records, non-human identity activity, authentication logs, service account ownership, prompt and response logs, message provenance, cryptographic signatures, session history, concurrent use, geolocation, user-agent data, and actor attribution fields. Particular attention should be given to shared identities, unmanaged agent accounts, actions logged as human but produced by a synthetic subject, impossible or concurrent use of one identity, and communications that lack verifiable agent-origin attribution.

Investigative Relevance

Identity misattribution and impersonation harm is relevant because synthetic subjects can blur the boundary between human, service, and agent action. The adverse outcome is not only that an identity was misused, but that people, systems, or records were caused to trust an incorrect actor.

This section is especially relevant where synthetic subjects communicate externally, approve workflows, transact through service accounts, operate under delegated human authority, interact with other agents, or generate synthetic audio, video, or text that mimics a trusted organizational figure.

Shared agent identity occurs when multiple synthetic subjects, workflows, tools, or deployments authenticate through the same service account, token, credential, or application identity.

This configuration creates an elevated exposure condition because activity cannot be cleanly attributed to a specific synthetic subject. Logs may show that a shared identity accessed data, called an Application Programming Interface (API), sent a message, or updated a record, without showing which agent or workflow caused the action.

The primary risk is attribution failure. If several synthetic subjects use the same identity, investigators may be unable to determine which one acted, whether the action was authorized, or which directive, invocation, tool, or input caused the event.

Investigators should review service account usage, token assignments, connector credentials, authentication logs, agent configuration files, workflow ownership, and identity governance records. Particular attention should be given to credentials reused across agents, vendors, environments, or business functions.

Investigative Relevance

Shared agent identity is relevant because identity separation is required to reconstruct synthetic subject behavior. Where multiple agents act through one credential, containment may require disabling several workflows at once, and accountability may remain unclear.

Long-lived agent credential occurs when a synthetic subject uses a token, secret, key, certificate, or service credential that remains valid for an extended period. This may include static Application Programming Interface (API) keys, persistent OAuth tokens, stored connector secrets, or credentials without automatic expiry.

This configuration creates an elevated exposure condition because leaked, copied, or misused credentials may remain usable long after the original deployment, workflow, or tool action. A long-lived credential can allow continued access even where the synthetic subject’s purpose has changed or the responsible owner is no longer monitoring it.

The primary risk is persistent unauthorized access. If a long-lived agent credential is exposed through logs, repositories, configuration files, browser storage, vendor tooling, or Model Context Protocol (MCP) server settings, an unauthorized party may act with the synthetic subject’s permissions until the credential is discovered and revoked.

Investigators should review token age, expiry settings, credential rotation history, vault records, access logs, connector configuration, repository exposure, and recent authentication activity. Particular attention should be given to credentials with no expiry, stale tokens, and credentials used after a deployment or integration was retired.

Investigative Relevance

Long-lived agent credentials are relevant because they extend the window in which a synthetic subject’s access can be misused. This sub-section is especially relevant where credentials grant access to customer data, production systems, mailboxes, cloud resources, or external tools.

Hard-coded agent secret occurs when a synthetic subject’s credential is stored directly in source code, configuration files, scripts, notebooks, environment templates, agent manifests, or Model Context Protocol (MCP) server settings.

This configuration creates an elevated exposure condition because credentials may be copied, committed, indexed, logged, shared, or exposed outside the intended runtime environment. Once embedded in code or configuration, the secret may persist across branches, build artifacts, backups, developer machines, and public repositories.

The primary risk is credential exposure leading to unauthorized synthetic subject access. An exposed secret may allow an unauthorized party to impersonate the agent, call connected tools, retrieve data, send messages, or act through the synthetic subject’s permissions.

Investigators should review repositories, configuration stores, build logs, deployment manifests, container images, MCP server files, and secret-scanning telemetry. Particular attention should be given to newly committed keys, secrets in public repositories, credentials in plaintext configuration, and hard-coded values reused across environments.

Investigative Relevance

Hard-coded agent secrets are relevant because they create a direct path from configuration exposure to synthetic subject impersonation. This sub-section is especially relevant where agents rely on static keys, local configuration files, marketplace tools, or developer-managed integration settings.

Orphaned agent identity occurs when a synthetic subject’s credential, service account, connector identity, token, or cloud role remains active after the agent, workflow, vendor tool, or integration it supported has been retired, replaced, or abandoned.

This configuration creates an elevated exposure condition because the identity may retain access without an active owner, business purpose, or monitoring expectation. Authentication by the orphaned identity may be mistaken for legacy system behavior or ignored because no current team clearly owns it.

The primary risk is uncontrolled residual access. An orphaned identity may still retrieve data, call Application Programming Interfaces (APIs), access cloud resources, or operate tools after the original synthetic subject is no longer in use. The access may be later repurposed, or become a candidate for misuse, causing validation of legitimate activity difficult, as well as attribution.

Investigators should review identity ownership, last-use timestamps, deployment records, connector inventories, access review results, vendor integrations, and decommissioning records. Particular attention should be given to active credentials linked to retired agents, inactive projects, disabled applications, former vendors, or undocumented workflows.

Investigative Relevance

Orphaned agent identities are relevant because they preserve access after operational need has ended. This sub-section is especially relevant during incident containment, vendor offboarding, platform migration, and synthetic subject decommissioning.

Uninventoried agent identity occurs when a synthetic subject authenticates through a credential, service account, token, connector, cloud role, or application identity that is not represented in asset inventory, identity governance, access review, or ownership records.

This configuration creates an elevated exposure condition because defenders may not know the identity exists, what it can access, who owns it, or which synthetic subject uses it. Without inventory coverage, the identity may fall outside monitoring, recertification, rotation, and decommissioning processes.

The primary risk is invisible authority. An uninventoried identity may continue accessing systems, retrieving data, or calling tools without being assessed as part of the organization’s synthetic subject risk surface.

Investigators should review identity provider records, cloud accounts, service principals, connector inventories, agent manifests, vendor integrations, authentication logs, and asset discovery outputs. Particular attention should be given to identities with no owner, no linked application, no documented purpose, or no access review history.

Investigative Relevance

Uninventoried agent identities are relevant because unknown identities cannot be reliably governed or contained. This sub-section is especially relevant where teams create experimental agents, vendor integrations, local automation, or Model Context Protocol (MCP) servers outside central identity processes.

Unattributed tool call occurs when a synthetic subject invokes a tool without logs that clearly preserve the tool name, arguments, result, invoking synthetic subject, non-human identity, human invoker, and downstream action.

This configuration creates an elevated exposure condition because investigators may see only the final system change, not the tool call that caused it. The action may appear to originate from a service account, host application, or employee rather than a specific tool invocation.

The primary risk is loss of reconstructable evidence. Without immutable tool-call logging, investigators may be unable to determine what the synthetic subject requested, what the tool returned, what data was exposed, or whether the action matched an approved directive.

Investigators should review tool-call logs, application logs, agent traces, audit trails, non-human identity records, request identifiers, and downstream system events. Particular attention should be given to missing arguments, missing results, overwritten logs, shared service identities, and actions that cannot be tied to a specific tool call.

Investigative Relevance

Unattributed tool calls are relevant because tool use is often where synthetic subject behavior becomes operational action. This sub-section is especially relevant where agents call APIs, send messages, write records, execute commands, or interact with external services.

Delegated user account access occurs when a synthetic subject is granted access to organizational systems through a human employee’s account authorization. This may include OAuth consent, connected application approval, browser authorization, account linking, or delegated access granted through a productivity, development, or business platform.

This configuration creates an elevated exposure condition because the synthetic subject can use permissions that were originally assigned to the employee. The employee may approve the connection once, while the synthetic subject continues to retrieve data, call tools, summarize content, or perform actions within the scope of that delegated grant.

The primary risk is inherited access without equivalent oversight. A synthetic subject may access mail, documents, repositories, records, or application data through the employee’s authorization, even where the employee does not review each retrieval or action.

Investigators should review OAuth grants, connected applications, user consent records, delegated permissions, application scopes, access logs, revocation history, and vendor integrations. Particular attention should be given to broad scopes, persistent grants, third-party AI services, and delegated access that bypasses central synthetic subject governance.

Investigative Relevance

Delegated user account access is relevant because it allows a synthetic subject to operate using permissions granted to a human account. This sub-section is especially relevant where employees authorize AI tools to access mailboxes, calendars, cloud drives, source repositories, customer records, or productivity suites.

Authenticated user session access occurs when a synthetic subject operates inside an employee’s active browser, desktop, or single sign-on session. This may include browser agents, desktop agents, computer-use agents, local assistants, or automation tools that interact with applications already authenticated as the employee.

This configuration creates an elevated exposure condition because the synthetic subject can act through the employee’s live session, cookies, tokens, permissions, and application state. It may navigate pages, read rendered content, submit forms, download files, copy data, or trigger actions as if the employee performed them directly.

The primary risk is session inheritance. The synthetic subject may access systems or perform actions without separately authenticating, and logs may show ordinary employee activity rather than AI-mediated behavior.

Investigators should review browser session records, endpoint telemetry, single sign-on logs, clipboard activity, form submissions, download history, visited URLs, automation traces, and application audit logs. Particular attention should be given to agent activity inside authenticated sessions, actions following external page interaction, and events lacking a distinct synthetic subject identity.

Investigative Relevance

Authenticated user session access is relevant because it allows a synthetic subject to use the employee’s active trust state. This sub-section is especially relevant where AI tools operate through browsers, remote desktops, local applications, cloud consoles, or authenticated business platforms.

Local user credential access occurs when a synthetic subject can access credentials, tokens, keys, certificates, session files, or secrets stored in an employee’s workstation or development environment. This may include environment variables, command-line profiles, password manager access, cloud configuration files, package registry tokens, Secure Shell (SSH) keys, local application secrets, or local AI tools that can control the computer through the keyboard, mouse, browser, terminal, or graphical user interface.

This configuration creates an elevated exposure condition because the synthetic subject may discover and use credentials that were not intentionally granted to it. Local assistants, coding agents, terminal-capable agents, browser agents, or computer-use agents may inherit access to files, sessions, shells, profiles, clipboard contents, credential stores, or environment state containing sensitive credentials.

The primary risk is unintended credential use. A synthetic subject may read, copy, transmit, or apply local credentials to access systems beyond its intended scope, including source repositories, cloud environments, databases, internal tools, or production services.

Investigators should review endpoint file access, shell history, environment variables, credential stores, local configuration files, password manager events, source repository access, browser activity, clipboard activity, and tool runtime permissions. Particular attention should be given to AI tools with file-system access, terminal access, browser control, graphical user interface control, broad workspace access, or access to developer credential locations.

Investigative Relevance

Local user credential access is relevant because credentials stored for human convenience may become usable by a synthetic subject. This sub-section is especially relevant where local AI assistants, coding assistants, terminal agents, browser agents, or computer-use agents operate on employee workstations with access to the same local resources as the user.

Unauthorized operator invocation occurs when a person causes a synthetic subject to act without legitimate authority to invoke it. This may involve stolen credentials, exposed interfaces, misconfigured access controls, abandoned accounts, weak authentication, public endpoints, or impersonation of an authorized user.

This invocation creates an elevated exposure condition because the synthetic subject may treat the request as valid and execute it using its standing identity, tools, permissions, and configured environment access. The unauthorized operator may not need direct access to the underlying systems if the synthetic subject can act on their behalf.

The primary risk is unauthorized use of synthetic subject authority. A person outside the approved operator set may use the synthetic subject to retrieve data, call tools, update records, send messages, run commands, or trigger workflows that they could not perform directly.

Investigators should review authentication records, session history, operator identity, access-control decisions, interface exposure, prompt logs, tool-call logs, affected systems, and downstream actions. Particular attention should be given to unusual operator accounts, impossible travel, first-time invocation, public interface exposure, failed authentication attempts, abandoned accounts, and tool calls inconsistent with the apparent operator’s role.

Investigative Relevance

Unauthorized operator invocation is relevant because the synthetic subject may become an access broker for an unauthorized person. The person does not need the same direct system permissions as the synthetic subject if they can successfully invoke it.

This section is especially relevant where synthetic subjects are exposed through internal web applications, chat interfaces, browser extensions, developer tools, workflow endpoints, Application Programming Interfaces (APIs), or vendor platforms with weak operator authentication or authorization.

Ambiguous actor attribution occurs when available logs or records show that an action happened, but do not identify the specific synthetic subject, human operator, tool, connector, workflow, or vendor-controlled component that caused it. The evidence may be intact and accurate, but still too general to support attribution.

This condition is distinct from log deletion or trace tampering. In ambiguous actor attribution, the problem is not necessarily that evidence was removed or altered. The problem is that the recorded actor is too broad, shared, or indirect to identify the real source of the action.

The primary risk is collapsed actor identity. A record update, message, tool call, or system change may be logged under a shared service account, delegated human identity, generic application identity, or workflow bot. The log may truthfully record that the shared identity acted, but fail to show which synthetic subject, operator prompt, tool call, or invocation path produced the action.

A related risk is containment uncertainty. If investigators cannot identify the responsible actor, they may have to disable broad identities, revoke multiple connectors, suspend unrelated workflows, or take larger containment actions than necessary. Conversely, they may fail to contain the true source if the apparent identity is only a shared proxy.

Investigators should review identity provider logs, service account ownership, non-human identity records, OAuth grants, connector identities, prompt and response logs, tool-call records, session context, agent identifiers, vendor audit fields, and actor attribution metadata. Particular attention should be given to shared service accounts, missing agent IDs, actions recorded only under a human identity, multiple agents using one credential, and vendor logs that collapse model, tool, and user activity into one actor.

Investigative Relevance

Ambiguous actor attribution is relevant because synthetic subjects often act through borrowed, shared, delegated, or vendor-managed identities. Even complete logs may be insufficient if they identify only the account used, not the synthetic subject or invocation that caused the action.

This condition is especially relevant where synthetic subjects use shared service accounts, delegated user sessions, marketplace connectors, Model Context Protocol (MCP) servers, human-attributed actions, vendor-hosted AI features, or orchestration platforms with multiple agents operating through the same identity.

Shared Non-Human Identity (NHI) attribution gap occurs when multiple synthetic subjects, users, sessions, tools, or workflows act through the same service account, credential, token, connector identity, or application identity. The logs may show that the shared identity acted, but not which synthetic subject, operator prompt, session, or human principal caused the action.

This condition frustrates investigation because the evidence is too broad to support reliable attribution. The issue is not necessarily missing logs or deleted records. The issue is that the recorded actor is a shared identity that collapses multiple possible actors into one audit trail.

The primary risk is loss of accountability. A database update, message, tool call, file access, Application Programming Interface (API) request, or workflow action may be logged under a single shared NHI. Investigators may be unable to determine whether the action was caused by one agent instance, another agent instance, an automated workflow, a connected tool, or a human operator acting through the same credential.

A related risk is containment uncertainty. If the responsible synthetic subject cannot be identified, responders may need to disable the entire shared identity, interrupt multiple workflows, revoke broad connectors, or suspend legitimate operations. Conversely, containment may fail if the true actor continues to operate through the same shared identity after one suspected agent is disabled.

Investigators should review service account ownership, credential assignment, token issuance, connector identity records, non-human identity activity, prompt and response logs, session identifiers, agent identifiers, human-principal binding, OAuth grants, Privileged Access Management (PAM) records, and downstream audit logs. Particular attention should be given to one credential exhibiting multiple behavioral patterns, concurrent use of the same identity, actions with no resolvable originating principal, static long-lived credentials, and service accounts used by multiple synthetic subjects.

Investigative Relevance

Shared NHI attribution gap is relevant because synthetic subjects often act through machine identities rather than direct human accounts. When multiple agents or workflows share one NHI, even complete logs may be insufficient to identify the true source of an action.

This condition is especially relevant where synthetic subjects use shared service accounts, static API keys, marketplace connectors, Model Context Protocol (MCP) servers, automation tokens, application identities, or vendor-managed credentials that do not preserve the originating user, session, agent, and invocation context.