Configuration

Access Through Non-Human Identity

Vendor-Embedded AI

ID: CF001
Created: 26th August 2026
Updated: 26th August 2026
Contributors: Nimer Kees, James Weston,

Access Through Non-Human Identity

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.

Subsections (7)

ID	Name	Description
CF001.007	Excessive Agency	Excessive agency occurs when a synthetic subject is configured with a combination of permissions, tools, functions, or action paths that exceed its approved operational purpose. This may include broad read access, write capability, administrative functions, production access, external communication authority, or permission to call high-impact tools. This configuration creates an elevated exposure condition because the synthetic subject is not only able to access information, but also to act on it. Excessive agency may allow the synthetic subject to retrieve data, modify records, send messages, trigger workflows, call Application Programming Interfaces (APIs), change configurations, or perform operational actions beyond what its role requires. The primary risk is excessive blast radius. A flawed directive, manipulated invocation, compromised tool, or unsafe model output may result in actions that affect systems, data, customers, or business processes outside the synthetic subject’s intended scope. This is especially significant where the synthetic subject holds standing access to privileged functions or where high-impact actions do not require separate approval. Investigators should review the synthetic subject’s permissions, tool access, functional capabilities, connector scopes, write privileges, administrative roles, external communication authority, and approval gates. Particular attention should be given to functions that allow data modification, external transmission, production change, financial action, security control alteration, or access to backup and recovery systems. Investigative Relevance Excessive agency is relevant because configuration determines not only what a synthetic subject can see, but what it can do. A limited assistant may become a high-impact synthetic subject if its permissions and functions allow it to act across systems without appropriate restriction.
CF001.004	Hard-Coded Agent Secret	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.
CF001.002	Long-Lived Agent Credential	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.
CF001.005	Orphaned Agent Identity	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.
CF001.003	Over-Scoped Agent Access	Over-scoped agent access occurs when a synthetic subject is granted permissions beyond what is required for its approved function. This may include broad read access, write permissions, administrative scopes, cross-repository access, tenant-wide connectors, or access to data classes unrelated to the task. This configuration creates an elevated exposure condition because any defective directive, manipulated invocation, compromised connector, or unsafe tool call may operate across a larger scope than necessary. The synthetic subject’s practical capability is defined by what its credentials allow, not by what its prompt says it should do. The primary risk is excessive blast radius. A synthetic subject intended to summarize tickets, answer questions, or process records may be able to retrieve confidential documents, access customer data, modify systems, or transmit information outside its intended boundary. Investigators should review assigned scopes, role grants, connector permissions, cloud roles, data access policies, tool permissions, and actual access patterns. Particular attention should be given to tenant-wide access, broad wildcard permissions, production write access, and access to sensitive repositories that are not required for the synthetic subject’s function. Investigative Relevance Over-scoped agent access is relevant because excessive permission turns routine AI behavior into high-impact operational risk. It is especially relevant where a low-risk assistant, embedded feature, or workflow agent has access normally reserved for privileged users or production services.
CF001.001	Shared Agent Identity	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.
CF001.006	Uninventoried Agent Identity	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.

Configuration

Access Through Human Identity