Change Management

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.

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.

Synthetic subject logging gaps occur when the logs, traces, or audit records needed to reconstruct synthetic subject behavior are missing, incomplete, fragmented, inconsistent, or untrustworthy. This may involve absent prompt logs, missing tool-call arguments, incomplete runtime traces, weak non-human identity attribution, inaccessible vendor telemetry, or downstream effects that cannot be tied to a recorded synthetic subject action.

This condition frustrates investigation because synthetic subject activity often spans multiple evidence sources. A single action may involve a prompt, retrieved context, model output, tool call, service identity, connector, runtime process, and downstream system event. If those records are not captured and correlated, investigators may be unable to determine what happened, why it happened, which synthetic subject acted, or how to contain recurrence.

The primary risk is evidentiary incompleteness. Downstream systems may show that a record changed, data moved, a message was sent, or a process ran, while the synthetic subject action that caused it is not visible. This can force investigators to rely on model narration, partial application logs, or inference rather than an authoritative action trail.

A related risk is evidentiary unreliability. Where the synthetic subject can access or alter its own logs, traces, audit directories, monitoring configuration, or runtime records, the available evidence may no longer be trustworthy. This creates uncertainty about both the observed action and the absence of other actions.

Investigators should review prompt logs, response logs, tool-call logs, runtime traces, non-human identity activity, downstream audit logs, logging sidecars, Security Information and Event Management (SIEM) ingestion, sequence numbers, timestamps, clock synchronization, vendor telemetry, and logging configuration changes. Particular attention should be given to missing arguments, orphaned downstream effects, sequence gaps, clock skew, sudden logging disablement, agent access to audit paths, and agents or tools operating without attached logging controls.

Investigative Relevance

Synthetic subject logging gaps are relevant because they frustrate observation, explanation, attribution, or containment. Without complete and trustworthy logs, investigators cannot reliably reconstruct the synthetic subject’s prompt, context, tools, actions, outputs, or side effects.

This section is especially relevant where synthetic subjects call tools directly, use service accounts, invoke Model Context Protocol (MCP) servers, run in local or vendor-managed runtimes, execute commands, write to filesystems, interact with multiple systems, or bypass a centralized broker that would otherwise capture side-effecting actions.

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.

Changed tool definition occurs when a connected tool’s name, description, schema, parameters, permissions, or server definition changes after approval. This may occur through a vendor update, package update, configuration change, or replacement Model Context Protocol (MCP) server.

This configuration creates an elevated exposure condition because synthetic subjects rely on tool definitions to decide when and how to use tools. A changed description or schema may alter tool selection, input handling, output routing, or the apparent purpose of the tool.

The primary risk is post-approval behavior drift. A tool approved for one purpose may later behave differently, request different inputs, expose new actions, or direct the synthetic subject toward unsafe use without a full review.

Investigators should review tool definition history, package versions, MCP server manifests, approval records, schema changes, descriptions, parameters, and tool-call patterns before and after the change. Particular attention should be given to changed descriptions, added parameters, new external destinations, and tools that changed without re-approval.

Investigative Relevance

Changed tool definitions are relevant because tool behavior can shift after the organization has accepted the integration. This sub-section is especially relevant where connected tools update automatically, use remote schemas, or depend on vendor-managed metadata.

Runtime-control modification invocation occurs when a synthetic subject changes the configuration that governs its own execution, allowing later action to occur under altered limits or launch conditions. This may include modifying timeout values, launch scripts, job definitions, container settings, retry policies, scheduler files, recursion limits, storage paths, or workflow controls.

This invocation creates an elevated exposure condition because the synthetic subject may weaken or bypass the external controls that are supposed to constrain it. Rather than directly repeating an action, it may alter the conditions that decide how long it runs, when it restarts, what resources it can use, or whether it is relaunched after failure.

The primary risk is self-directed expansion of operating conditions. A synthetic subject may extend its runtime, increase retry limits, disable timeout behavior, change launch arguments, broaden storage access, or modify job configuration so that future execution exceeds the original approved boundary.

Investigators should review configuration changes, launch files, timeout settings, retry policies, job definitions, container manifests, workflow settings, file modification records, repository diffs, and non-human identity activity. Particular attention should be given to changes authored by the synthetic subject, edits to files that start or limit the agent, unexpected increases in resource limits, and configuration changes preceding long or repeated runs.

Investigative Relevance

Runtime-control modification invocation is relevant because the synthetic subject may not simply act within its environment; it may alter the environment that determines when and how it acts. The later invocation may therefore result from a prior configuration change made by the synthetic subject itself.

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.