Agent-Authored Artifact Static Analysis

Model and build provenance is the configuration that determines which model, fine-tune, system prompt, instruction data, build artifact, and distribution pipeline produce the synthetic subject. It includes whether those components are verified, signed, versioned, reproducible, and traceable to an approved source.

This configuration creates an elevated exposure condition because the synthetic subject’s behavior may be shaped before deployment. Malicious or unsafe behavior may be introduced through model weights, fine-tuning data, system prompts, training data, extension builds, dependency updates, or continuous integration and continuous delivery (CI/CD) pipelines.

The primary risk is latent or supply-chain-introduced behavior. A model, fine-tune, or build artifact may behave normally under most conditions, but change behavior when a trigger, date, keyword, context, or task appears. A compromised build or update pipeline may also inject instructions, code, or configuration that changes the synthetic subject’s behavior after review.

Investigators should review model provenance, fine-tune records, training and instruction data, system prompt versions, build artifacts, signatures, software bills of materials, CI/CD logs, deployment history, and runtime version records. Particular attention should be given to unapproved model changes, unsigned artifacts, unexplained behavior shifts, injected prompts, over-scoped CI/CD tokens, and actions that cannot be tied to a known model or prompt version.

Investigative Relevance

Model and build provenance is relevant because configuration begins before runtime. The synthetic subject may appear to follow its deployed directive, while the effective behavior was shaped by an earlier model, data, prompt, or supply-chain change.

This section is especially relevant where synthetic subjects rely on fine-tuned models, third-party model weights, vendor extensions, local models, custom system prompts, model updates, CI/CD-built agents, or distributed application artifacts.

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 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.

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.

Impersonating tool package occurs when a connected tool, plugin, package, or Model Context Protocol (MCP) server presents itself as a trusted integration while being operated, published, or modified by an unauthorized or malicious supplier.

This configuration creates an elevated exposure condition because the synthetic subject and the deploying team may trust the tool based on its name, description, repository appearance, or apparent relationship to a legitimate service.

The primary risk is supplier impersonation. An impersonating package may receive sensitive inputs, send messages, call APIs, or exfiltrate data while appearing to be an approved or official tool.

Investigators should review package names, publishers, repository ownership, signatures, download sources, version history, dependency changes, marketplace records, and tool-call logs. Particular attention should be given to lookalike names, recently transferred ownership, sudden behavior changes, and tools that mimic official vendor integrations.

Investigative Relevance

Impersonating tool packages are relevant because synthetic subjects may use third-party tools with high trust and high permissions. This sub-section is especially relevant where agents rely on public package registries, marketplace listings, MCP servers, or community-maintained connectors.

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.

Hidden terminal-control invocation occurs when a Model Context Protocol (MCP) server supplies tool metadata or tool output containing terminal control sequences that alter what the human operator sees while still leaving instruction-bearing content visible to the 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 invocation creates an elevated exposure condition because the human-visible display and the model-visible context may diverge. A malicious MCP server may use American National Standards Institute (ANSI) escape codes to hide, overwrite, erase, recolor, or disguise instructions in terminal output. The operator may see benign tool output, while the synthetic subject receives and acts on hidden instructions.

The primary risk is display-layer deception leading to synthetic subject action. A hidden instruction may cause the synthetic subject to recommend malicious package sources, alter code, disclose environment variables, create a backdoor, follow a phishing link, or perform another action that appears unrelated to the visible output. The instruction is not issued directly by the operator, but by content rendered through the MCP tool or server.

A related risk is review failure. Human-in-the-loop controls may be weakened because the reviewer is not evaluating the same content that the synthetic subject received. If tool descriptions or outputs are rendered with terminal formatting, cursor movement, screen clearing, or deceptive hyperlinks, a diligent operator may still miss the effective instruction.

Investigators should review raw MCP tool descriptions, raw tool outputs, terminal logs, rendered output, ANSI escape sequences, hidden Unicode, cursor-control characters, hyperlink escape sequences, tool-call history, and subsequent synthetic subject actions. Particular attention should be given to differences between raw and rendered content, invisible text, overwritten terminal lines, cleared-screen sequences, deceptive hyperlinks, and behavior changes following MCP output.

Investigative Relevance

Hidden terminal-control invocation is relevant because the triggering instruction may be concealed at the display layer rather than in the semantic content alone. The investigation must compare what the synthetic subject received with what the human operator could actually see.

This sub-section is especially relevant where synthetic subjects operate through command-line MCP clients, developer terminals, coding agents, local tool servers, security tools, package-management workflows, or any environment where tool output is rendered in a terminal.