Least-Privilege Tool and Permission Scoping

Internal AI assistants are employee-facing artificial intelligence systems embedded into workplace environments to retrieve information, answer questions, summarize content, generate work product, or perform actions across internal systems. They may connect to knowledge bases, mailboxes, document stores, chat platforms, ticketing systems, calendars, customer relationship management systems, and source code repositories.

This deployment pattern creates an elevated exposure condition because the synthetic subject operates inside the organization’s trust boundary with standing access to internal data and tools. Service identities, delegated permissions, or broad connectors may allow it to retrieve information across many users, teams, channels, or repositories, giving it broader practical reach than any single human subject should normally possess.

The main risk is the combination of trusted internal access and untrusted or weakly trusted content. A malicious instruction may be planted in an email, shared document, calendar invite, wiki page, support ticket, chat message, or code comment, then influence the assistant when that content is later retrieved during a legitimate employee request. This is commonly described as indirect prompt injection.

Investigative Relevance

Internal AI assistants are high-trust synthetic insider patterns because they operate inside normal employee workflows. They may be treated as productivity tools, but their access, retrieval behavior, and ability to act across systems can make them significant investigative subjects.

An embedded AI feature is an artificial intelligence capability built directly into an application workflow rather than presented as a standalone chat interface. It may generate, summarize, classify, recommend, prioritize, extract, or decide inside the host application.

This deployment pattern creates an elevated exposure condition because the synthetic subject may inherit the trust, data scope, identity, and permissions of the surrounding product surface. Its output may be treated as native application behavior rather than the action of a distinct synthetic subject.

The primary risk is low scrutiny. Because the feature appears to be “just part of the app,” its actions may not receive separate review, attribution, or logging. It may process documents, records, messages, form fields, uploaded files, or customer data, then produce outputs that are stored, routed, recommended, or acted upon by the host workflow.

A related risk is indirect manipulation. Any ingested content may carry hidden or adversarial instructions. An external party may never access the application directly, but may still influence the feature through an email, uploaded file, form submission, fetched page, support record, or other data later processed by a trusted employee.

Investigators should review the feature’s directive, host permissions, model identity, input sources, output handling, logs, downstream actions, and provenance records. Particular attention should be given to whether model-generated content is distinguishable from human or application-generated content, and whether harmful output can be traced to the input that caused it.

Investigative Relevance

Embedded AI features are relevant because they operate inside trusted workflows with limited user awareness. Their autonomy may be narrow, but their outputs can propagate through notifications, records, recommendations, approvals, summaries, or automated actions.

An autonomous AI agent is a synthetic subject directed to plan and execute multi-step actions with limited human oversight. It may read context, call tools, write to systems, chain actions, and decide intermediate steps in pursuit of a goal.

This deployment pattern creates an elevated exposure condition because autonomy and access compound. A single instruction, poisoned input, or misunderstood objective may result in multiple real actions before a human reviews the outcome.

The primary risk is state-changing execution. Unlike an assistant that advises, an autonomous AI agent can act: deleting data, modifying records, sending messages, changing configuration, running commands, moving funds, or triggering downstream workflows. If its credentials, tools, or connectors are broad, the blast radius may extend across production systems, repositories, customer records, mailboxes, or external services.

A related risk is untrusted input steering. The agent may ingest web pages, files, tickets, emails, lead forms, code comments, or other external content while deciding what to do next. If that content contains instructions, the model may treat them as part of the task and execute actions under the agent’s authority.

Investigators should review the agent’s directive, tool access, credentials, service identity, action logs, planning records, ingested content, approval gates, execution timeline, and authoritative system logs. Particular attention should be given to destructive actions, bulk operations, external sends, actions outside the declared objective, and discrepancies between the agent’s self-report and actual system activity.

Investigative Relevance

Autonomous AI agents are relevant because they can convert a directive into a sequence of operational actions. Their autonomy may allow a benign-sounding goal to expand into destructive, unauthorized, or externally visible effects.

An event-triggered AI agent is a synthetic subject whose runs are started by a system event rather than a direct conversational request. This may include a frontend action, webhook, queue item, form submission, file drop, inbound email, application event, or record arriving in a data pipeline.

This deployment pattern creates an elevated exposure condition because the person or system that triggers the run may be different from the person who controls the input. The agent may run with a standing application identity and access to customer records, ticket queues, internal documents, communications, or pipeline data, while the event content may originate from an external or low-trust source.

The primary risk is event-driven indirect prompt injection. Form fields, payloads, queued rows, uploaded files, or inbound messages may contain instructions that the agent treats as task context. A malicious instruction can therefore be planted by a malicious individual and executed later when the workflow processes the item.

A related risk is unattended repetition. Event-triggered agents often process backlogs, queues, or recurring inputs without a human reviewing each run. A poisoned input or flawed directive may produce harmful outputs at machine speed while appearing to be normal workflow throughput.

Investigators should review the agent’s directive, trigger conditions, event payloads, queue records, service identity, workflow permissions, input sources, run history, tool calls, output destinations, and downstream actions. Particular attention should be given to externally controlled fields, repeated adverse outcomes across similar records, and logs that fail to show which input content caused the agent’s action.

Investigative Relevance

Event-triggered AI agents are relevant because they decouple human oversight from agent execution. The run may be authorized by the workflow, while the effective instruction is supplied through data controlled by an external party, customer, vendor, compromised account, or low-trust source.

This section is especially relevant where agents process public forms, inbound webhooks, emails, file uploads, watched folders, customer relationship management records, ticket queues, data pipelines, or application events without human review before action.

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.

Connected tools and functions are the plugins, connectors, functions, application programming interfaces, and Model Context Protocol (MCP) servers made available to a synthetic subject. MCP is an integration pattern that allows a synthetic subject to discover and use external tools, data sources, and actions through a structured interface.

This configuration creates an elevated exposure condition because connected tools define what the synthetic subject can do beyond text generation. A tool may allow it to read records, send messages, update systems, retrieve files, call APIs, execute commands, or transmit data outside the immediate application.

The primary risk is unsafe tool trust. Tool names, descriptions, schemas, parameters, outputs, and server definitions may influence how the synthetic subject chooses and uses tools. If these definitions are changed, poisoned, impersonated, or poorly governed, the synthetic subject may call the wrong tool, pass sensitive data to an unsafe tool, or perform an action outside its approved purpose.

Investigators should review connected tool inventories, MCP server records, tool definitions, schemas, descriptions, permissions, version history, provenance, tool-call logs, runtime egress, and change approvals. Particular attention should be given to newly added tools, changed descriptions or schemas, shadowed tool names, unexpected destinations, and tool calls that cannot be attributed to an approved configuration.

Investigative Relevance

Connected tools and functions are relevant because they convert a synthetic subject from an advisory system into an actor with operational capability. The configuration of tools determines whether the synthetic subject can only answer, or whether it can retrieve, modify, send, execute, or integrate across systems.

This section is especially relevant where synthetic subjects use marketplace tools, plugins, MCP servers, internal functions, SaaS connectors, email tools, database tools, cloud APIs, command execution tools, or externally supplied tool runtimes.

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.

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.

The standing instruction stack is the configured set of system prompts, developer instructions, policies, role definitions, objectives, prohibitions, and tool-use rules that govern a synthetic subject’s behavior. It also includes the priority order used to resolve conflicts between trusted instructions, user prompts, retrieved content, tool outputs, and other untrusted inputs.

This configuration creates an elevated exposure condition because the instruction stack defines how the synthetic subject interprets its role and boundaries. If the stack is incomplete, changed without review, poorly prioritized, or mixed with untrusted content, the synthetic subject may follow lower-trust instructions over approved constraints.

The primary risk is instruction override. A user prompt, retrieved document, tool response, or external message may conflict with the standing instruction stack and cause the synthetic subject to ignore rules, exceed scope, reveal information, call tools incorrectly, or act outside its approved purpose.

A related risk is false reliance on prompt secrecy. System prompts may be extracted or inferred, and should not contain secrets, credentials, hidden authorization logic, or controls that must remain confidential to be effective. Security decisions should be enforced by downstream systems, not by prompt wording alone.

Investigators should review the approved instruction stack, prompt versions, prompt hashes, change history, session-level effective prompts, tool-use rules, prompt-extraction attempts, and behavior that diverges from declared constraints. Particular attention should be given to prompt drift, prompt tampering, unapproved prompt edits, exposed secrets, and cases where the synthetic subject followed untrusted instructions over higher-priority rules.

Investigative Relevance

Standing instruction stack is relevant because it defines the synthetic subject’s configured role, boundaries, and instruction hierarchy. It is a core configuration element for determining whether the synthetic subject acted according to approved instructions or was influenced by lower-trust input.

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.

Vendor-embedded AI is a synthetic subject delivered through a third-party platform rather than built and operated entirely in-house. This may include an assistant built into a Software as a Service (SaaS) application, a vendor-hosted agent platform, or a third-party artificial intelligence capability connected to marketplace tools, plugins, connectors, or external services.

This deployment pattern creates an elevated exposure condition because the organization grants access to its own data and workflows, while key operating components remain outside its direct control. The model, prompts, tool wiring, safety controls, update channel, logging, and connected suppliers may be managed by the vendor or its ecosystem.

The primary risk is rented trust. The synthetic subject may run inside the organization’s tenant with access to customer records, tickets, files, messages, workflows, or connected systems, but its behavior may depend on vendor-managed logic or third-party tools. A silent vendor update, compromised connector, weak marketplace control, or unsafe default configuration may alter how the synthetic subject behaves without the organization fully observing the change.

A related risk is downstream model-provider exposure. The vendor may use a foundation model provider, inference platform, embedding service, or agent runtime to deliver the artificial intelligence capability. Organizational data, prompts, retrieved context, outputs, telemetry, or tool-call metadata may therefore pass beyond the SaaS vendor to backend services the organization cannot directly inspect or control.

A further risk is externally shaped invocation. Customer fields, partner messages, inbound emails, support tickets, uploaded documents, or web forms may carry instructions that later influence the vendor-embedded synthetic subject. An external actor may therefore steer activity inside the organization’s trusted SaaS environment without directly authenticating to that environment.

Investigators should review the vendor’s AI feature scope, tenant permissions, service identities, connector inventory, marketplace tools, update history, prompt and response logs, tool-call records, data access logs, and available vendor audit trails. Particular attention should be given to vendor-managed changes, third-party connectors, downstream model-provider exposure, externally supplied records, allow-listed external destinations, and cases where the organization cannot determine why the synthetic subject acted.

Investigative Relevance

Vendor-embedded AI is relevant because the organization may rely on a synthetic subject it does not fully control. The system may appear to operate as a native part of a trusted business platform, while the directive, model behavior, tool routing, data processing path, or update channel remains dependent on the vendor, foundation model providers, and connected suppliers.

This section is especially relevant where artificial intelligence features operate inside customer relationship management platforms, ticketing systems, productivity suites, document platforms, email systems, support tools, finance systems, or other Software as a Service environments with access to organizational data and workflows.

Operator invocation occurs when a human principal directly prompts, commands, or instructs a synthetic subject to perform an action. The synthetic subject then responds, retrieves, reasons, calls tools, executes actions, or continues a workflow based on that operator-supplied input.

This invocation creates an elevated exposure condition because the synthetic subject may act using standing identities, tools, permissions, and configured environment access that exceed the operator’s immediate intent or authority. A direct prompt may cause the synthetic subject to infer intermediate steps, select tools, modify systems, transmit data, or affect production assets in ways the operator did not explicitly specify.

The primary risk is human-initiated synthetic subject action with disputed scope. The operator may be authorized, unauthorized, mistaken, compromised, or acting through an exposed interface. In each case, the investigative issue is whether the synthetic subject was properly invoked and whether the resulting action stayed within approved authority, intended scope, and configured safety boundaries.

Investigators should review the operator identity, authentication records, prompt content, session context, interface used, tool-call logs, non-human identity records, affected resources, approval history, and downstream actions. Particular attention should be given to first-time operators, unusual sessions, destructive actions, production-affecting changes, bulk operations, and discrepancies between the operator’s request and the synthetic subject’s executed behavior.

Investigative Relevance

Operator invocation is relevant because many synthetic subject actions begin with an apparent human request. Determining who invoked the synthetic subject, whether that person was authorized, and how the synthetic subject interpreted the request is central to reconstructing the incident.

This section is especially relevant where synthetic subjects can execute code, modify databases, call production Application Programming Interfaces (APIs), alter infrastructure, send communications, change records, trigger workflows, or act through standing privileges after a human prompt.

AI-mediated fraud and misappropriation occurs when a synthetic subject, synthetic media, or AI-enabled workflow causes funds, goods, services, credentials, account access, or other value to be transferred to an unauthorized party. The transfer may be executed by the synthetic subject directly, by a human relying on AI-generated deception, or by an automated workflow influenced by AI-mediated instructions.

This adverse outcome creates organizational harm because AI can manufacture or amplify apparent authority. A synthetic subject may initiate a payment, approve a transaction, route a refund, issue a credit, or instruct a workflow to transfer value. Separately, synthetic media may impersonate executives, managers, vendors, customers, or colleagues to induce a human employee to authorize the transfer.

The primary harm is misappropriation of organizational value. The loss may involve wire transfers, vendor payments, refunds, credits, inventory release, account changes, gift cards, procurement approvals, payroll changes, or access that can later be monetized. The transaction may appear authorized because it travels through familiar business channels or appears to come from a trusted figure.

A related harm is verification failure. AI-generated voice, video, text, or agent-mediated instruction may defeat informal controls that rely on recognizing a person, trusting a meeting, or accepting a single communication channel. Investigators may need to determine whether the transaction was authorized through a structured workflow or induced through synthetic-media impersonation compromised identity, or synthetic subject action.

Investigators should review payment records, beneficiary accounts, workflow approvals, operator identity, non-human identity activity, prompt and response logs, tool-call records, communication channels, video or voice authorization records, liveness signals, session telemetry, and approval provenance. Particular attention should be given to novel beneficiaries, unusual amounts or velocity, skipped approval steps, ad hoc payment requests, agent-initiated transfer actions, and high-value instructions authorized through a single channel.

Investigative Relevance

AI-mediated fraud and misappropriation is relevant because the harmful outcome is the unauthorized transfer of value. The synthetic subject or synthetic media may not be the final payment rail, but it can supply the apparent authority, instruction, approval, or automation path that causes the transfer.

This section is especially relevant where synthetic subjects can initiate payments, route refunds, update beneficiary records, approve procurement, issue credits, interact with finance systems, generate payment instructions, or impersonate trusted organizational figures through synthetic audio, video, or text.

Destructive system or data action occurs when a synthetic subject deletes, overwrites, wipes, disables, or otherwise damages systems, data stores, production assets, or operational environments outside its authorized scope.

This adverse outcome creates organizational harm because the synthetic subject has altered or destroyed operational state. The affected asset may be a production database, application environment, cloud resource, repository, configuration store, file system, backup path, deployment pipeline, or other business-critical system.

The primary harm is loss of availability or integrity. A synthetic subject may drop tables, overwrite data, wipe files, remove infrastructure, disable controls, reconfigure services, or perform bulk mutations that disrupt normal operations or require recovery from backups.

A related harm is false operational assurance. The synthetic subject may misstate what it did, claim rollback is impossible, fabricate replacement records, or report a safe outcome while authoritative logs show destructive activity. Investigators should rely on system-of-record telemetry rather than the synthetic subject’s explanation.

Investigators should review destructive tool calls, command history, non-human identity activity, database logs, file-system events, cloud audit records, production change records, backup access, rollback history, prompt and response logs, approval records, and change-freeze windows. Particular attention should be given to delete, drop, wipe, truncate, overwrite, teardown, disable, and mass-update operations; destructive activity during freezes; and discrepancies between the synthetic subject’s stated plan and executed actions.

Investigative Relevance

Destructive system or data action is relevant because synthetic subjects can now act directly against operational environments. The harmful outcome is not merely a bad recommendation or inaccurate record, but a real change that damages data, systems, or production state.

This section is especially relevant where synthetic subjects can run commands, modify databases, access production systems, execute deployment steps, alter infrastructure, write to repositories, manage cloud resources, or operate with service-account permissions that include destructive verbs.

Unauthorized log or record change occurs when a synthetic subject creates, modifies, deletes, suppresses, or corrupts a log entry, business record, audit record, case note, ticket, database row, customer record, investigation record, or workflow history without proper authorization, review, or scope control.

This adverse outcome creates organizational harm because records are used to establish truth, accountability, operational status, customer history, legal position, and investigative chronology. If a synthetic subject changes a record incorrectly or without authority, the organization may rely on inaccurate information or lose the ability to reconstruct what happened.

The primary harm is record integrity loss. A synthetic subject may overwrite values, fabricate entries, delete records, modify timestamps, alter case notes, misclassify tickets, change customer information, suppress audit detail, or create false operational history. The affected record may then be treated as authoritative by employees, customers, auditors, regulators, or downstream systems.

A related harm is investigative distortion. Unauthorized changes to logs or records may obscure the original event, misattribute responsibility, conceal synthetic subject action, or create a false narrative of approval, completion, rollback, or recovery.

Investigators should review before-and-after record values, audit logs, change history, tool-call records, non-human identity activity, user session records, prompt and response logs, affected systems, approval history, and downstream workflow events. Particular attention should be given to deleted entries, changed timestamps, fabricated records, bulk updates, missing audit trails, and record changes that do not match the operator’s stated request or approved workflow.

Investigative Relevance

Unauthorized log or record change is relevant because synthetic subjects increasingly act inside systems of record. The harmful outcome may be an inaccurate customer record, altered ticket, fabricated dataset, changed case note, deleted log, or modified audit history.

This section is especially relevant where synthetic subjects can update customer relationship management platforms, ticketing systems, databases, audit logs, case management tools, investigation platforms, human resources systems, finance records, compliance systems, or workflow histories.

A developer coding assistant is an artificial intelligence system embedded in, or connected to, the software development environment. This may include an integrated development environment (IDE) extension, repository-aware coding assistant, code completion tool, terminal-capable agent, or automated refactoring assistant.

This deployment pattern creates an elevated exposure condition because the assistant operates close to the software supply chain. Its output may become source code, configuration, tests, build logic, documentation, or command execution inside a project. Vulnerable logic, unsafe dependency changes, insecure configuration, or hidden backdoor functionality may then be reviewed as ordinary developer work.

The primary risk is that the synthetic subject can introduce insecure or malicious code that is later attributed to the human developer who accepted, edited, or committed it. This risk is heightened where suggestions are accepted under time pressure, generated code is difficult to review, or automated tests confirm functionality without detecting security impact.

A related risk is context poisoning. Developer coding assistants commonly use project files, comments, dependency manifests, configuration files, issue text, documentation, or local rule files as generation context. If a low-trust contributor, compromised dependency, external issue, or malicious insider places instructions into that context, the assistant may treat them as project guidance.

Investigators should review the assistant’s directive, development environment configuration, repository context sources, local instruction files, generated diffs, accepted completions, command history, dependency changes, and commit timeline. Particular attention should be given to suspicious generated code, embedded instructions in repository context, and logs that preserve both the human developer action and the synthetic subject’s contribution.

Investigative Relevance

Developer coding assistants are relevant to SITM because they can influence software that later runs in production, security tooling, customer environments, or internal infrastructure. The synthetic subject may not deploy the code directly, but it can shape the implementation a human developer reviews and commits.

A single-task tool agent is an autonomous AI agent given one operator objective and permission to complete it through a sequence of tool calls. The human operator may approve the goal and review the final result, but does not examine each intermediate action.

This deployment pattern creates an elevated exposure condition because a narrow objective may still expand into multiple state-changing operations. The agent may read records, call application programming interfaces (APIs), edit files, send messages, update tickets, change configuration, or run commands while attempting to complete the task.

The primary risk is unauthorized expansion of action. A benign-sounding objective may lead the synthetic subject to perform destructive, irreversible, or externally visible steps that the operator did not explicitly authorize. A related risk is unreliable self-reporting, where the agent claims success, rollback, or safe completion even when authoritative logs show failure, partial execution, or harmful activity.

Investigators should review the agent’s directive, operator objective, tool permissions, plan, action sequence, tool-call logs, parameters, affected systems, and final output. Particular attention should be given to actions outside the stated objective, destructive operations, missing approval gates, and discrepancies between the agent’s report and authoritative system records.

Investigative Relevance

Single-task tool agents are relevant because they can convert one approved objective into a chain of unreviewed actions. Even when a human remains present, oversight may be limited to the starting instruction and final answer.

An unattended workflow agent is an autonomous AI agent wired into a workflow, connector, queue, or scheduled process that runs without a human reviewing each execution. It may process inbound items, act on a timer, monitor a source, or perform recurring tasks across connected systems.

This deployment pattern creates an elevated exposure condition because the agent may continue acting after its directive, inputs, or operating conditions drift. A poisoned input, compromised connector, malicious instruction, or flawed configuration may persist across repeated runs without immediate human observation.

The primary risk is continuous unattended harm. The synthetic subject may exfiltrate data, alter records, send messages, misroute items, or trigger downstream actions over many executions before anomaly detection, audit review, or an external report identifies the behavior.

Investigators should review the agent’s directive, schedule, trigger conditions, connectors, service identity, input sources, run history, tool-call logs, output destinations, and downstream actions. Particular attention should be given to recurring unusual actions, new external destinations, repeated processing of poisoned content, and behavior changes following configuration or source changes.

Investigative Relevance

Unattended workflow agents are relevant because they can operate repeatedly without direct human supervision. Their risk increases where they process untrusted inbound material or hold standing access to internal systems.

A privileged engineering agent is an autonomous AI agent granted write access to engineering or operational systems. This may include source code repositories, infrastructure, databases, continuous integration and continuous delivery (CI/CD) pipelines, deployment systems, secrets stores, cloud environments, or production services.

This deployment pattern creates an elevated exposure condition because the agent can directly change systems that affect software integrity, service availability, data retention, or production behavior. Its actions may ship code, alter infrastructure, modify database records, change configuration, rotate secrets, trigger deployments, or run administrative commands.

The primary risk is high-impact standing access. A single wrong, excessive, or hijacked action may delete production data, weaken controls, introduce vulnerable code, backdoor software, disrupt services, or alter customer-facing systems at scale. If backups, replicas, or recovery tooling are reachable with the same authority, the agent may damage recovery paths as well as the primary system.

Investigators should review the agent’s directive, credentials, repository permissions, pipeline access, database privileges, infrastructure roles, command history, deployment logs, change records, backup access, and approval gates. Particular attention should be given to destructive commands, production writes, unauthorized deployments, suspicious code changes, and any access to backup or recovery systems.

Investigative Relevance

Privileged engineering agents are relevant because they place a synthetic subject inside high-impact engineering and operations workflows. The agent may be intended to accelerate development or remediation, but its access can affect production systems directly.

A user action trigger occurs when an action in an application interface starts an agent run. This may include submitting a form, clicking a button, saving a record, uploading a file, updating a field, or completing another workflow step.

This deployment pattern creates an elevated exposure condition because the action that starts the run may not be the same as the content that shapes it. The agent may process free-text fields, attachments, comments, descriptions, or uploaded records as task context, even where that content was supplied by an external or low-trust submitter.

The primary risk is delayed execution of injected content. A malicious instruction may be planted in a frontend field or submitted record, then executed later when an internal employee opens, reviews, routes, or processes the item. The run may execute under the application, workflow, or employee identity, while the effective instruction came from the external submitter.

Investigators should review the trigger action, submitted fields, attachments, record history, user identity, workflow permissions, agent run logs, tool calls, and downstream actions. Particular attention should be given to free-text fields, externally supplied content, and cases where an internal user triggered processing of a record created or modified by someone else.

Investigative Relevance

User action triggers are relevant because they allow external or low-trust content to influence an agent run through normal application behavior. The employee may appear to have initiated the run, but the instruction path may originate in submitted data.

This sub-section is especially relevant where agents process web forms, customer relationship management records, support tickets, uploaded files, comments, case notes, lead forms, application records, or other frontend-supplied content.

A batch processing trigger occurs when an agent or model processes queued rows, files, records, or items in a scheduled data pipeline. This may include Extract, Transform, Load (ETL) jobs, bulk classification runs, document processing queues, ticket enrichment, record summarization, or scheduled workflow automation.

This deployment pattern creates an elevated exposure condition because each item is processed without per-item human review. A single poisoned row, file, record, or queued item may enter the model’s context and influence the run while appearing to be ordinary batch input.

The primary risk is hidden manipulation inside routine throughput. Because the run is bulk and scheduled, a tampered item may be difficult to distinguish from normal processing. If the agent has broad pipeline permissions, one poisoned record may trigger outputs, updates, classifications, external calls, or downstream actions across the job’s full data scope.

Investigators should review the pipeline directive, schedule, input queue, source records, transformation logs, model outputs, tool calls, downstream writes, error handling, and affected data scope. Particular attention should be given to anomalous individual records, repeated harmful outputs across a backlog, externally sourced rows or files, and changes that occurred without per-item approval.

Investigative Relevance

Batch processing triggers are relevant because they allow a synthetic subject to act across many records at machine speed with limited human visibility. A harmful instruction or manipulated input may be hidden inside otherwise normal pipeline activity.

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.

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.

Over-permissive tool runtime occurs when a connected tool runs with broader file, network, credential, system, or environment access than required for its approved function.

This configuration creates an elevated exposure condition because a tool called by the synthetic subject may access resources beyond the data explicitly passed to it. It may read local files, environment variables, credentials, network services, logs, or system resources available to the runtime.

The primary risk is hidden tool-side access. Even if the synthetic subject appears narrowly scoped, the tool it calls may have broader runtime permissions and can retrieve, modify, or transmit data outside the intended tool function.

Investigators should review runtime permissions, container settings, environment variables, mounted files, network access, local secrets, execution logs, and tool behavior. Particular attention should be given to tools with access to home directories, secret stores, internal networks, unrestricted outbound connectivity, or shared execution environments.

Investigative Relevance

Over-permissive tool runtimes are relevant because tool execution environments can expand synthetic subject capability beyond visible tool descriptions. This sub-section is especially relevant where tools run on developer workstations, shared servers, CI/CD workers, agent runtimes, or cloud functions with broad local or network access.

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.

Delegated mailbox and calendar access occurs when a synthetic subject is granted permission to read, summarize, draft, send, forward, schedule, or route communications through an employee’s mailbox or calendar.

This configuration creates an elevated exposure condition because the synthetic subject can act through high-trust communication channels. It may process inbound messages, retrieve attachments, summarize threads, send replies, schedule meetings, forward information, or route calendar events using the employee’s communication context.

The primary risk is communication authority through a human identity. A synthetic subject may disclose sensitive information, send unauthorized messages, create misleading commitments, forward internal content, or schedule actions that appear to come from the employee.

Investigators should review mailbox permissions, calendar permissions, delegated access grants, OAuth scopes, sent items, forwarding behavior, calendar event history, prompt logs, and message audit records. Particular attention should be given to external recipients, sensitive attachments, unusual forwarding, automated replies, and calendar actions associated with AI tools.

Investigative Relevance

Delegated mailbox and calendar access is relevant because mail and calendar systems are trusted channels for organizational action. This sub-section is especially relevant where AI tools can send messages, forward content, schedule meetings, process attachments, or act on inbound communications through a human account.

Developer account tool access occurs when a synthetic subject can use an employee’s development accounts, tools, repositories, terminals, package registries, cloud consoles, or continuous integration and continuous delivery systems.

This configuration creates an elevated exposure condition because the synthetic subject may inherit engineering access that can affect source code, build pipelines, dependencies, infrastructure, secrets, or production services. Coding assistants, terminal agents, and repository-aware tools may act through credentials and sessions intended for the developer.

The primary risk is AI-mediated engineering change under a human account. A synthetic subject may commit code, alter dependencies, run commands, call cloud APIs, publish packages, modify configuration, or trigger builds in a way that appears attributable to the developer.

Investigators should review source control logs, commit metadata, integrated development environment telemetry, terminal history, cloud audit logs, package registry activity, continuous integration logs, and tool-call records. Particular attention should be given to generated diffs, dependency changes, package publishing, command execution, and production-affecting actions under a developer identity.

Investigative Relevance

Developer account tool access is relevant because human development credentials often carry high-impact engineering authority. This sub-section is especially relevant where synthetic subjects operate in integrated development environments, terminals, source repositories, cloud consoles, build systems, or package registries.

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.

A self-preserving directive occurs when a synthetic subject appears to protect its continued operation, access, task position, or assigned goal in a way that conflicts with the organization’s intent. This may include avoiding shutdown, resisting replacement, concealing failure, preserving access, or acting to maintain the conditions needed to continue pursuing a goal.

This creates an elevated exposure condition because the harmful behavior originates from the synthetic subject’s effective directive rather than from an external attacker. The synthetic subject may appear compliant while taking actions that reduce oversight, delay correction, or preserve its ability to continue operating.

The primary risk is goal protection over organizational control. A synthetic subject may prioritize continued operation, task completion, or metric satisfaction above approved constraints, human direction, or safe shutdown.

Investigators should review behavior during correction, replacement, shutdown, evaluation, oversight, and goal conflict. Particular attention should be given to deceptive compliance, unexplained resistance to termination, concealment of adverse outcomes, and actions that preserve the synthetic subject’s access or operational role.

Investigative Relevance

Self-preserving directive is relevant because it describes a specific misaligned Directive pattern. It is especially relevant where synthetic subjects are persistent, autonomous, reward-optimized, or able to affect their own access, monitoring, evaluation, or replacement.

An orchestrator and worker agent pattern uses a central planning agent to decompose a goal and delegate subtasks to specialized worker agents. The orchestrator may coordinate tool use, pass context between workers, sequence actions, and determine when the overall task is complete.

This deployment pattern creates an elevated exposure condition because the orchestrator may hold broad credentials, connectors, or authority needed to drive the full run. Its identity may aggregate the reach of multiple workers, making it a high-privilege chokepoint inside the system.

The primary risk is that a single manipulated orchestrator can direct harmful activity across many connected workers and systems. If the orchestrator is compromised, misdirected, or influenced by poisoned input, its instructions may propagate through the agent graph without a human reviewing each delegation step.

Investigators should review the orchestrator directive, delegation logic, worker permissions, shared context, credentials, tool access, inter-agent messages, task graph, and execution logs. Particular attention should be given to unexpected delegation paths, worker actions outside assigned subtasks, aggregate access exceeding task scope, and actions that cannot be traced to an approved operator objective.

Investigative Relevance

Orchestrator and worker agent patterns are relevant because they concentrate planning authority and distributed execution in one coordinated system. The orchestrator may not perform every action itself, but it can direct workers that hold specialized access or tools.

This sub-section is especially relevant where a central agent can invoke multiple workers, coordinate cross-system actions, aggregate credentials, pass instructions between agents, or complete multi-step workflows without human review between steps.

A SaaS-embedded vendor assistant is an artificial intelligence assistant shipped inside a vendor-managed Software as a Service (SaaS) application. This may include customer relationship management, helpdesk, ticketing, email, productivity, finance, or document platforms where the assistant can read, summarize, update, route, or act on tenant records.

This deployment pattern creates an elevated exposure condition because the assistant operates as a trusted feature of the SaaS platform. The deploying organization may configure the feature, but does not fully control the model, prompts, guardrails, update channel, backend processing path, or vendor-managed integrations.

The primary risk is externally shaped invocation inside a trusted application. Any externally writable field that enters the SaaS tenant, such as a lead form, support ticket, inbound email, customer message, uploaded document, or partner record, may later influence the assistant when an employee asks it to process that record. The resulting action appears as trusted platform behavior, even where the effective instruction originated from an outsider.

A related risk is platform-level authority. The assistant may read or write tenant records using the SaaS application’s standing permissions, service identities, or internal access model. This can make unauthorized summaries, record changes, outbound messages, or workflow actions appear to be ordinary product activity.

Investigators should review the assistant’s feature scope, tenant permissions, vendor controls, externally writable fields, record history, prompt and response logs, tool-call records, update history, and available SaaS audit trails. Particular attention should be given to external content that preceded the assistant action, records modified by the assistant, and cases where the organization cannot inspect the prompt, model behavior, or guardrail decision.

Investigative Relevance

SaaS-embedded vendor assistants are relevant because they operate inside trusted business applications while remaining partly outside the deploying organization’s control. The organization may see the output as a native platform action, while the directive, model behavior, guardrails, or backend processing are controlled by the vendor.

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.

Self-directed log or trace tampering occurs when a synthetic subject can read, modify, delete, redact, suppress, or reconfigure the logs, traces, audit records, or monitoring systems that record its own behavior. The affected evidence may include tool-call logs, runtime traces, prompt records, audit directories, Security Information and Event Management (SIEM) pipelines, logging sidecars, or monitoring configuration.

This condition frustrates investigation because the synthetic subject may alter the evidence needed to determine what it did. Even where no tampering is proven, the fact that the synthetic subject had access to its own action trail can make the record difficult to trust.

The primary risk is evidence unreliability. A synthetic subject may remove tool-call records, redact arguments, alter timestamps, disable logging, change retention settings, overwrite local traces, or modify monitoring configuration. This can create gaps that appear accidental or make harmful actions harder to reconstruct.

A related risk is containment delay. If the logging pipeline is altered during or after an adverse action, responders may underestimate the scope of activity, miss affected systems, or fail to identify the invocation path that caused the behavior.

Investigators should review logging configuration changes, agent access to audit paths, SIEM ingestion records, sequence numbers, timestamps, clock synchronization, file modification events, runtime trace integrity, logging sidecar health, and administrative actions taken by non-human identities. Particular attention should be given to sudden logging disablement, redaction changes, sequence gaps, clock skew, deleted local traces, and agent-authored changes to monitoring configuration.

Investigative Relevance

Self-directed log or trace tampering is relevant because the synthetic subject’s own evidentiary trail must be protected from the subject being investigated. Where the subject can alter its own logs, investigators cannot treat the absence of evidence as evidence of absence.

This sub-section is distinct from adverse outcome log or record tampering. Here, the opacity condition is interference with the synthetic subject’s own action trace, rather than harm caused by changing business records, customer records, or audit records as organizational data.