Synthetic Subject Access Review

Enterprise retrieval access is the configuration of corpora, indexes, connectors, and Retrieval-Augmented Generation (RAG) pipelines that a synthetic subject can retrieve from. A corpus is a collection of documents, records, messages, files, or other source material made available for search or retrieval. RAG is a design pattern where relevant source material is retrieved before the synthetic subject generates an answer or takes action.

This configuration creates an elevated exposure condition because retrieval defines what internal information can enter the synthetic subject’s context. If retrieval spans mailboxes, documents, tickets, customer records, wikis, source code, or other enterprise stores, the synthetic subject may combine information across repositories, sensitivity levels, and access boundaries.

The primary risk is retrieval beyond entitlement. A synthetic subject may retrieve, summarize, or expose information that the human requester is not authorized to view. This may occur through shared indexes, broad connectors, cached embeddings, service identities, incomplete query-time access checks, or retrieval pipelines that do not enforce per-user permissions.

A related risk is untrusted content in retrieval context. Externally sourced documents, inbound emails, customer records, support tickets, uploaded files, or partner content may be indexed and later retrieved into the synthetic subject’s context. If that content contains malicious or misleading instructions, it may influence the synthetic subject during an otherwise legitimate request.

Investigators should review retrieval configuration, connected corpora, index membership, connector permissions, query logs, documents returned, requester identity, access-control decisions, prompt and response records, and output destinations. Particular attention should be given to cross-boundary retrieval, sensitive content in outputs, externally sourced documents, and cases where retrieved material exceeded the requester’s entitlement.

Investigative Relevance

Enterprise retrieval access is relevant because retrieval configuration determines what information a synthetic subject can see and use. Weak retrieval boundaries may turn an assistant or agent into a bridge between restricted information and an unauthorized requester.

This section is especially relevant where synthetic subjects retrieve from enterprise search indexes, RAG pipelines, mailboxes, file stores, collaboration platforms, ticketing systems, customer relationship management platforms, source repositories, or shared document corpora.

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.

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.

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.

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.

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.

Privileged user access occurs when a synthetic subject operates through an administrator, security, finance, Human Resources, legal, production support, or other high-impact human account.

This configuration creates an elevated exposure condition because the synthetic subject inherits sensitive access assigned to the privileged user. It may operate inside administrative consoles, security tools, finance systems, personnel records, production environments, cloud platforms, or regulated data stores.

The primary risk is privileged action without equivalent human control. A synthetic subject may retrieve sensitive records, modify controls, approve transactions, change configurations, access secrets, run commands, or expose regulated data while appearing to act as the privileged employee.

Investigators should review privileged session logs, administrative actions, security tool activity, cloud audit records, finance approvals, personnel record access, endpoint telemetry, prompt records, and tool-call logs. Particular attention should be given to AI tool activity during privileged sessions, actions outside normal administrative workflows, and changes lacking clear human review.

Investigative Relevance

Privileged user session access is relevant because it places a synthetic subject inside the highest-impact human access paths. This sub-section is especially relevant where AI tools assist administrators, security analysts, finance users, legal staff, Human Resources personnel, production engineers, or other privileged roles.