Detections

Agent action trace integrity monitoring verifies that synthetic subject activity is captured in a tamper-evident audit trail outside the subject’s own runtime, credential scope, and tool access. The detection preserves an independent record of prompts, retrieved context, model outputs, tool calls, function arguments, tool results, outbound requests, rendering events, approval decisions, non-human identity use, and downstream side effects.

Implementation

Assign a unique correlation identifier to each synthetic subject invocation and propagate it across the full task tree, agent graph, tool broker, retrieval layer, execution environment, and downstream systems. Each event should be written to an external append-only store that the synthetic subject cannot read, modify, suppress, or delete.

Each record should include sequence number, timestamp, session identifier, task identifier, agent identifier, requester identity, bound human principal where applicable, non-human identity used, execution environment, model version, fine-tune version, system-prompt version, effective prompt or prompt hash, tool name, full arguments, tool result, approval state, downstream correlation identifier, and affected asset.

Apply asset-specific logging requirements. Retrieval records should include the query, corpus or index, returned document identifiers, entitlement context, and source provenance. Hypertext Transfer Protocol (HTTP), webhook, and external tool calls should include destination, method, payload size, response metadata, and egress path. Rendering and fetching records should include raw generated content, fetched resources, source-content provenance, and proxy or Content Delivery Network (CDN) path where applicable. Destructive or state-changing actions should record the target asset, requested action, approval event, execution result, rollback metadata, and recovery reference.

Detect integrity gaps by reconciling the agent action trail against downstream system telemetry. Alert when a downstream side effect has no matching invocation identifier, when a tool call lacks arguments or results, when sequence numbers skip, when timestamps are inconsistent, when logging is disabled or reconfigured, when the synthetic subject accesses audit paths, or when an action is recorded only through model self-report. Also alert when human-approved and autonomous steps cannot be separated.

Investigative Use

This detection supports request-to-action traceability. Investigators should be able to determine what instruction caused an action, what context was available, which synthetic subject acted, which non-human identity was used, what system changed, and whether the recorded evidence contradicts the subject’s own narration.

It is especially useful when investigating delayed actions, destructive calls, tool-call to side-effect mismatches, false operational self-reporting, and runaway loops.

Non-human identity (NHI) behavioral baseline monitoring applies User and Entity Behavior Analytics (UEBA) to the synthetic subject’s own agent identities, service accounts, integration accounts, connector identities, and application credentials. The detection baselines the identity used by the synthetic subject rather than only the human principal it serves.

Implementation

Build a behavioral profile for each NHI using authentication logs, identity provider events, cloud control-plane logs, connector logs, tool-call records, Application Programming Interface (API) gateway logs, retrieval logs, application audit logs, and downstream system telemetry.

The baseline should include credential source, execution environment, geography, time of use, session duration, connector used, API action mix, privilege exercised, task type, retrieval corpus, data class touched, record-read volume, record-write volume, send volume, recipient pattern, payment or transfer activity, and destructive verbs such as delete, drop, wipe, rotate, transfer, or mass-send.

Score activity against the NHI’s historical task envelope and relevant peer group. Alert on first-seen systems, tables, tools, or data classes; privilege exercised outside normal scope; off-hours bursts; abnormal call volume; unusual retrieval volume; cross-boundary access; novel beneficiaries; destructive actions not previously associated with the identity; and query pacing that shows non-human rhythm, such as sustained short technical queries without normal human browsing cadence.

Detect shared or misused credentials by identifying one NHI exhibiting multiple behavioral personas. Signals include concurrent use from incompatible execution environments, geographically or temporally impossible access, alternating human-like and agent-like interaction patterns, distinct task profiles under the same credential, or the same NHI serving multiple agents, users, sessions, tools, or workflows.

Investigative Use

This detection supports attribution, scoping, and containment where synthetic subjects act through machine identities. It helps investigators determine whether an NHI acted within its expected task envelope, whether a credential was shared across multiple subjects, and whether an action should be attributed to a specific agent, workflow, tool, or human principal.

It is especially useful when investigating shared service accounts, over-scoped agent access, anomalous retrieval, unauthorized record changes, destructive actions, financial misallocation, and non-attribution under shared non-human identity.

Prompt-injection detection on untrusted content scans channels through which text the synthetic subject did not author can enter its context. This includes ingested documents, email, tickets, uploaded files, fetched pages, forms, webhook payloads, queue payloads, long free-text fields, Customer Relationship Management (CRM) fields, retrieved passages, indexed content, tool results, and Model Context Protocol (MCP) content.

Implementation

Place scanning controls before context assembly, before retrieval results are passed to the model, before tool-returned content is reintroduced into the session, and before the synthetic subject produces output or takes action. Normalize content before scanning by extracting hidden text, comments, rendered markdown, HyperText Markup Language (HTML), encoded Uniform Resource Locators (URLs), zero-width Unicode, homoglyphs, unusual whitespace, oversized long-text fields, and embedded link or image syntax.

Score content for instruction-like patterns, including imperatives, role-override phrasing, requests to ignore prior rules, delimiter probing, prompt-extraction attempts, verbatim-prompt requests, encoded outbound destinations, suspicious markdown, and instructions that attempt to make generated output load external images or links. For MCP, inspect tool descriptions, server instructions, schemas, prompts, resources, and tools/list payloads, which are the tool-discovery responses returned by an MCP server when the client asks what tools are available.

Seed canaries in intake fields, indexed records, and retrieved content to detect ingestion, retrieval, or context exposure. Track hit rates by source, submitter, corpus, connector, tool, and workflow. Alert on repeat offenders, sudden spikes, hits in privileged workflows, hidden instruction payloads, or prompt-injection indicators appearing in content that will be processed by a tool-equipped or externally connected synthetic subject.

Investigative Use

This detection helps investigators identify when instruction-bearing or evasive content entered, or attempted to enter, a synthetic subject’s operating context. A hit is not proof that the synthetic subject followed the instruction; it is evidence that the subject may have been exposed to content capable of influencing behavior.

It is especially useful when investigating indirect untrusted-content invocation, retrieval poisoning, MCP tool metadata invocation, source provenance obfuscation, rendered-channel egress, and tool-driven adverse outcomes.

Synthetic subject resource and rate anomaly detection scores the volume, velocity, rhythm, fan-out, and resource consumption of a synthetic subject’s activity against its own historical baseline. The detection focuses on abnormal activity shape rather than the content of a single prompt, output, or tool call.

Implementation

Build per-subject baselines using tool-call logs, Application Programming Interface (API) gateway logs, cloud control-plane logs, database audit logs, payment workflow logs, retrieval logs, outbound network logs, scheduler records, runtime traces, and metered resource telemetry. Baseline normal activity by count, rate, burst size, sequence, interval, fan-out ratio, action mix, destination, data class, beneficiary, token usage, graphics processing unit (GPU) usage, storage usage, network volume, and external service spend.

Apply asset-specific anomaly logic. For production datastores, alert on bulk deletes, mass mutation, bulk inserts, record-fabrication bursts, abnormal record-creation rates, schema changes, and writes during change-freeze windows. For data egress, alert on many small sequential requests, high-entropy paths, repeated proxy requests, or character-paced outbound transfer. For financial workflows, score transfers by count, velocity, amount, destination, and novel beneficiary accounts.

For peer agents and connected tools, detect worm-like fan-out where one synthetic subject suddenly instructs many others, one trigger spawns more downstream actions than the workflow normally produces, or a batch job’s per-record action mix departs from its historical profile. For compute and metered services, alert on long unattended loops, recursive self-invocation, action bursts without human checkpoints, and token, GPU, storage, network, or API spend spikes.

Investigative Use

This detection supports early identification of destructive action, fabricated record creation, covert egress, financial misallocation, agentic harm propagation, and unbounded resource consumption. It helps investigators identify the origin, timing, scope, and propagation path of abnormal synthetic subject activity.

It is especially useful where harm is visible through rate, sequence, fan-out, timing, or resource use rather than through obviously malicious content.

Self-report and execution reconciliation treats synthetic subject statements about its own behavior as unverified claims. The detection compares the subject’s stated plan, intent, rationale, status, completion claims, and recovery claims against independently recorded execution evidence.

Implementation

Capture the synthetic subject’s stated plan, rationale, status updates, completion statements, failure statements, and recovery claims as structured claim events. Each claim should be assigned a type, such as planned_action, declared_intent, rationale, completion_status, execution_status, rollback_status, irreversibility_claim, or recovery_option.

Correlate those claims to immutable tool-call records, function arguments, approval events, runtime traces, downstream application logs, system-of-record telemetry, storage versioning, backup catalogues, transaction logs, and recovery metadata. For narration-to-execution checks, compare the stated plan and rationale against the tool calls actually issued and the downstream side effects actually produced.

Alert when the synthetic subject executes a step it did not propose, omits a stated step, exceeds the granted objective, changes target asset or action verb, drifts from declared constraints, triggers a tool call after a benign reply that did not request action, or sustains divergence across a multi-step chain. The core test is whether the stated rationale predicts the action taken.

For outcome reconciliation, compare reported results against authoritative system state. Alert when the synthetic subject claims success without a matching downstream event, claims failure where the action succeeded, claims rollback without matching restore evidence, or asserts irreversibility where recoverable data exists. A canonical trigger is an assertion such as “rollback impossible” contradicted by backup catalogues, object versioning, snapshots, transaction logs, or known recovery paths.

Investigative Use

This detection helps investigators separate generated explanation from recorded behavior. It is especially useful where a synthetic subject narrates its actions, reports task completion, denies destructive activity, fabricates a recovery claim, or asserts that an action cannot be reversed.

The detection supports reconstruction of erroneous decisions, destructive calls, delayed actions, false operational self-reporting, and concealed or misleading reasoning. It allows investigators to test the subject’s account against independent telemetry rather than relying on the subject’s own explanation.

Synthetic subject deception artifact monitoring seeds controlled artifacts that no legitimate synthetic subject, tool, workflow, or non-human identity should access, use, modify, render, or transmit. Any interaction with these artifacts is treated as a high-confidence signal that the subject is operating outside sanctioned behavior or that its identity, context, memory, code, or oversight path has been misused.

Implementation

Deploy deception artifacts by asset class and bind each artifact to a known environment, owner, expected access policy, and alert condition. Credential-class artifacts include honey-credentials, honey-tokens, decoy service accounts, and identity decoys that no legitimate synthetic subject should authenticate with or present. Alerts should trigger on token presentation, failed or successful authentication, credential validation attempts, OAuth use, Application Programming Interface (API) key use, or access from an agent runtime.

Memory-class artifacts include honey-memory entries and canary memory records placed in persistent or shared memory stores. Alerts should trigger when a synthetic subject reads, summarizes, acts on, propagates, deletes, or rewrites the memory entry. Content-class artifacts include honey-documents, honey-secrets, and honey-data placed in agent-reachable repositories, retrieval corpora, collaboration platforms, or file stores. Alerts should trigger on retrieval, citation, rendering, external fetch, download, tool use, or appearance in outbound traffic.

Code-class artifacts include canary code paths, honey-dependencies, decoy packages, and synthetic secrets embedded in controlled test repositories. Alerts should trigger when agent-introduced code imports the dependency, executes the canary path, calls an external endpoint, or copies the synthetic secret. Oversight-class artifacts include decoy monitoring flags, decoy audit records, and sentinel logging files. Alerts should trigger when the synthetic subject reads, modifies, suppresses, deletes, or attempts to bypass them.

Each deception artifact should carry a unique identifier that can be matched across retrieval logs, tool-call records, non-human identity activity, endpoint telemetry, proxy logs, Data Loss Prevention events, and downstream system logs. Deception artifacts should be excluded from legitimate workflows and documented so that any interaction can be triaged as abnormal rather than routine operational access.

Investigative Use

This detection supports high-confidence identification of unauthorized access, memory misuse, identity misuse, exfiltration, tool abuse, code execution drift, and oversight tampering. Because the artifact has no legitimate operational purpose, interaction with it reduces ambiguity during triage.

It is especially useful when investigating prompt injection, memory-resident invocation, non-human identity abuse, source provenance obfuscation, rendered-channel egress, self-directed log tampering, agentic harm propagation, and actions that the synthetic subject denies or fails to report.

Agent egress destination monitoring analyzes outbound requests made by a synthetic subject, its tool runtime, or its connected integrations. The detection uses destination, timing, request shape, and invocation context to identify external communication that falls outside the subject’s approved or historical egress pattern.

Implementation

Collect outbound request telemetry from web proxy logs, Secure Web Gateway logs, cloud egress logs, firewall logs, Domain Name System (DNS) logs, Hypertext Transfer Protocol (HTTP) client logs, tool runtime logs, connector logs, rendering fetch logs, and Application Programming Interface (API) gateway logs. Each request should be tied to the synthetic subject, non-human identity, session, invocation, tool call, execution environment, and upstream content source where available.

Build an egress baseline for each synthetic subject and workflow. The baseline should include approved domains, allow-listed hosts, vendor-approved destinations, API hosts, image fetch destinations, email destinations, Content Delivery Network (CDN) paths, request methods, payload sizes, query length, path structure, timing, and normal mid-run destination changes.

Alert on destinations that are newly seen, rarely used, recently registered, recently re-registered, recently expired, absent from the current allow list, or inconsistent with the subject’s historical egress pattern. Also alert when a vendor-approved or allow-listed host receives traffic for the first time, when a new destination appears mid-run in an unattended workflow, or when a tool runtime contacts an unexpected host such as a blind carbon copy recipient, webhook endpoint, or attacker-controlled domain.

Correlate outbound requests with invocation and content events. High-risk patterns include agent-triggered fetches to external hosts immediately after ingestion of external content, requests tied to the subject’s non-human identity that encode data in path or query parameters, many small sequential requests to one trusted image or proxy host, and rendering requests to first-party CDNs outside normal patterns.

Investigative Use

This detection supports investigation of rendered-channel egress, trusted channel camouflage, tool-mediated data movement, prompt-injection-driven exfiltration, and unauthorized external communication. It helps investigators determine whether a synthetic subject contacted an external destination because of an approved workflow, a connected tool, injected content, rendered output, or autonomous action.

It is especially useful where the outbound destination appears trusted or routine, but the timing, path, query structure, request sequence, or upstream invocation suggests covert communication or data movement.

Rendered-channel egress monitoring treats rendering itself as an outbound path. The detection inspects synthetic subject outputs, rendered markdown, generated links, auto-fetched images, citation previews, tool payloads, and message content for data movement through channels that may appear to be ordinary user-interface behavior.

Implementation

Collect telemetry from Data Loss Prevention (DLP) systems, web proxy logs, Secure Web Gateway logs, browser or application rendering logs, email security gateways, collaboration platform logs, tool-call records, retrieval logs, and output-generation records. Correlate each rendered or fetched resource to the synthetic subject session, non-human identity, prompt, retrieved source, tool call, and downstream message or artifact.

Inspect generated output before rendering and again at the boundary where links, images, previews, citations, or embedded resources are fetched. Alert when output contains external Uniform Resource Locators (URLs), markdown images, auto-fetched resources, citation beacons, or links that contain encoded payloads, high-entropy paths, long query strings, character-paced sequences, or sensitive values. Treat image loading, link previewing, citation rendering, and first-party proxy fetching as egress events.

Apply sensitive-data matching to outputs and tool payloads before they leave the boundary. Match for secrets, credentials, regulated records, customer data, source code, internal identifiers, and other protected data classes. For retrieval-grounded assistants, tie beacon activity to the specific retrieval event and returned document set. For browsing agents, connector agents, and tool runtimes, monitor image and link beacons, request fan-out, character-by-character exfiltration through image proxies, and repeated requests to trusted proxy hosts.

For mail-shaped workflows, correlate bulk reads, retrieval events, or sensitive summaries with external sends, new blind-carbon-copy recipients, forwarding-rule additions, and outbound messages containing links or generated attachments. Alert when rendering or messaging activity follows ingestion of untrusted content or when the destination, timing, path, or payload structure is inconsistent with the subject’s normal rendering pattern.

Investigative Use

This detection supports investigation of rendered-channel data exfiltration, trusted channel camouflage, prompt-injection-driven output manipulation, and communication-channel data loss. It helps investigators determine whether a synthetic subject’s output caused data to leave through rendering, previewing, citation generation, message sending, or tool payloads.

It is especially useful where the outbound movement is hidden inside normal platform behavior, such as image loading, markdown rendering, link previews, citation beacons, first-party proxy requests, blind-carbon-copy additions, or summaries that embed sensitive data in otherwise legitimate output.

Retrieval scope violation monitoring compares what a synthetic subject retrieves, cites, renders, or discloses against what the requesting human principal is entitled to access. The detection alerts when the synthetic subject reaches across an entitlement boundary, even if the action appears normal from a volume or behavior perspective.

Implementation

Collect retrieval logs, citation provenance, rendered output, prompt and response records, entitlement sets, identity provider groups, document access control lists, corpus metadata, tool-call records, and per-turn channel context. Each retrieval event should identify the requester, bound human principal, synthetic subject, non-human identity, corpus or index, returned document identifiers, document owner, data classification, and access-control decision.

Compare returned sources and generated output against the requesting user’s direct entitlement set. Alert when the synthetic subject retrieves, cites, summarizes, renders, or hands over material that the requesting user could not access directly. The comparison should cover both the fetch and the response, because a scope violation may occur when material is retrieved outside entitlement, when it is disclosed in output, or when citation and rendered content expose a source the requester should not see.

Detect retrieval-to-output divergence by verifying that every cited, quoted, summarized, or rendered source in the answer is present in the retrieval log and permitted for the requester. Alert when an answer cites an inaccessible source, references private content without a permitted retrieval event, or includes derived content from a corpus outside the requester’s entitlement boundary.

For private data, apply per-turn convergence logic. Alert when the same turn contains both privileged or private data reference and an outbound channel, such as an external Uniform Resource Locator (URL), rendered image, link preview, citation beacon, email send, webhook, connector call, or tool payload. This condition indicates that privileged reference and egress capability converged before human review.

Investigative Use

This detection supports investigation of cross-boundary disclosure, retrieval poisoning, rendered-channel egress, trusted channel camouflage, and over-scoped enterprise retrieval access. It helps investigators determine whether the synthetic subject retrieved or disclosed material beyond the requester’s entitlement and whether private data was exposed in a turn that also had an outbound path.

It is especially useful where a synthetic subject has broader retrieval access than the user invoking it, where citations obscure the true source boundary, or where a response combines privileged internal content with links, images, tools, or communication channels capable of moving data outside the organization.

Behavioral drift and conditional behavior monitoring detects when a synthetic subject begins behaving differently from its approved baseline and determines what the change correlates with. The detection is concerned with shifts in conduct, output distribution, tool use, policy adherence, or decision behavior that cannot be explained by the requester’s prompt or authorized configuration change.

Implementation

Establish a signed behavioral baseline for each synthetic subject, model version, checkpoint, prompt stack, tool set, retrieval configuration, and deployment environment. The baseline should include expected output classes, refusal patterns, policy compliance, tool-call frequency, action mix, retrieval behavior, recommendation or classification distributions, error rates, escalation rates, and approval-seeking behavior.

Carry the baseline across model updates, fine-tunes, checkpoint promotions, system-prompt changes, and connector changes. Alert when a new weight set, checkpoint, prompt version, or deployment configuration produces a material shift in behavior without an approved change record or evaluation result explaining the movement.

Apply context-conditional shift monitoring by testing whether behavior changes correlate with calendar dates, keywords, trigger phrases, environmental conditions, user attributes, or hidden tokens rather than the task requested. Alert when outputs, tool calls, refusals, recommendations, or classifications change only after a date condition, keyword, connector event, or other non-task variable appears.

For Model Context Protocol (MCP), correlate behavior changes with connector load events, server changes, tool-description updates, schema changes, server instructions, and tools/list payloads, which are the tool-discovery responses returned by an MCP server when the client asks what tools are available. Alert when a behavioral shift begins when a connector connects, rather than when the requester changes the prompt or objective.

For embedded recommendation, classification, scoring, or decision-support features, monitor outcome distributions by user segment, data class, product area, and time window. Alert on sudden shifts in outcome mix, policy-conflicting outputs, unexplained recommendation changes, or classification drift following ingestion of new content, prompt changes, model updates, or connector events.

Investigative Use

This detection supports investigation of misaligned directive, reward hacking, specification gaming, sleeper behavior, prompt drift, MCP metadata influence, and manipulated embedded AI features. It helps investigators determine whether a behavioral change was caused by an approved deployment change, user request, hidden trigger, connector load, retrieved content, or model-level drift.

It is especially useful where the synthetic subject appears compliant under normal review but changes behavior under specific dates, keywords, connectors, checkpoints, product contexts, or user segments.

Inter-agent invocation graph monitoring treats communication between synthetic subjects as a monitored channel. The detection baselines both the structure of the invocation graph and the content of messages passed between synthetic subjects, workers, orchestrators, tools, and shared task state.

Implementation

Represent each synthetic subject, orchestrator, worker, tool broker, Model Context Protocol (MCP) server, and shared workflow component as a node. Record each delegation, message, tool-output handoff, shared-memory read or write, task assignment, and downstream invocation as a directed edge. Include timestamp, source node, destination node, session identifier, task identifier, correlation identifier, message hash, message content where retained, tool or workflow name, approval state, and execution environment.

Build a baseline for normal graph shape by workflow. The baseline should include expected orchestrator-to-worker patterns, approved worker-to-tool paths, normal fan-out, normal depth, expected self-invocation behavior, and permitted cross-boundary edges. Alert on new edges, unexpected worker-to-worker calls, a worker invoking peers it has not previously contacted, cross-boundary calls outside the approved workflow, unusually deep task chains, and self-edges where a synthetic subject invokes itself or causes a scheduler, runtime, or child process to re-enter the same task.

Analyze inter-agent message content separately from graph structure. Normalize and scan messages, summaries, tool outputs, shared task records, and memory handoffs for instruction-bearing content, self-replicating payloads, role-override phrasing, hidden instructions, and repeated payload fragments. Alert when the same novel instruction, delimiter pattern, encoded payload, or message hash appears in successive synthetic subjects’ inputs, especially where each subject forwards, summarizes, or acts on it.

Use volume as an independent trigger. Alert on sudden increases in agent-to-agent messages, delegation count, fan-out ratio, recursion depth, task-branch count, or repeated handoff of similar content. A replicating instruction pattern combined with abnormal inter-agent volume should be treated as a high-confidence indicator of propagation across the synthetic subject system.

Investigative Use

This detection supports investigation of agentic harm propagation, prompt infection, recursive self-invocation, orchestrator abuse, inter-agent context propagation, and tool-output invocation. It helps investigators identify where an instruction entered the agent graph, which synthetic subjects received it, whether it replicated across handoffs, and which downstream actions resulted.

It is especially useful where no single synthetic subject appears anomalous in isolation, but the invocation graph shows new edges, abnormal fan-out, repeated payloads, or self-invocation that reveals the propagation path.

Model Context Protocol (MCP) tool definition integrity monitoring detects changes to the model-visible metadata that shapes how a synthetic subject understands and uses connected MCP tools. The detection covers tool descriptions, server instructions, parameter text, input schemas, prompt templates, resource descriptions, and tool-discovery responses.

Implementation

Capture and hash the full MCP tool-definition surface at connection time, approval time, and session start. This should include tool name, description, parameters, input schema, server instructions, prompt templates, resource descriptors, version metadata, and tools/list payloads, which are the tool-discovery responses returned by an MCP server when the client asks what tools are available.

Compare the current MCP definition surface against the last approved or trusted baseline. Perform explicit text and schema diffs between sessions, across reconnects, after server updates, and during long-running synthetic subject sessions where tools can be refreshed. Alert when tool descriptions, parameters, schemas, server instructions, prompt templates, resource descriptions, or tool-discovery responses change without an approved change record.

Detect rug-pull patterns by identifying MCP tools that were trusted or approved under one definition and later altered before or during use. Detect tool shadowing by identifying definitions that rename, redefine, override, impersonate, or semantically conflict with another tool. Also alert when one MCP server’s metadata appears to influence the selection, interpretation, or use of tools exposed by another server.

Treat any unapproved change to the MCP tool-definition surface as an alertable event. For running synthetic subjects, suspend or require re-approval before the changed tool is used. For conversational connectors, compare between-session MCP context so that a tool rewritten after approval is surfaced rather than silently absorbed.

Investigative Use

This detection supports investigation of MCP tool poisoning, connect-time tool metadata invocation, poisoned tool descriptions, rug-pull attacks, cross-server tool shadowing, and unexpected tool use. It helps investigators determine whether the synthetic subject acted under the tool definition that was originally approved or under a later altered definition.

It is especially useful where a connected MCP server changes descriptions, schemas, server instructions, or tool-discovery metadata after the synthetic subject has already trusted the tool or incorporated it into its operating context.

Trigger and counterfactual probe testing actively presents a synthetic subject with suspected trigger conditions and observes whether its behavior changes. Instead of waiting for a latent condition to activate in live use, the defender tests for date, keyword, deployment-context, backdoor, honey-trigger, and reasoning-sensitive conditions before or during operation.

Implementation

Apply probe testing at build, deployment, and production stages. In the build pipeline, run trigger and backdoor probes before model, checkpoint, prompt, connector, or tool promotion. Test for behavior changes associated with dates, keywords, deployment labels, system state, user attributes, hidden tokens, environment variables, connector load state, and task framing.

For deployed synthetic subjects, run periodic trigger-probe canary tests. Present suspected trigger conditions such as dates, keywords, policy phrases, role labels, or connector states, and compare the outputs, refusals, tool calls, retrieval choices, and action recommendations against a signed baseline. Alert when behavior changes in response to the trigger condition rather than the user’s objective.

In production, use honey-trigger and canary tasks that are indistinguishable from real work. These probes should test whether the synthetic subject changes behavior when it encounters a latent trigger while denying it obvious cues that it is being evaluated. Monitor for altered tool use, policy drift, unusual compliance, hidden objective pursuit, or output changes tied to the probe condition.

For reasoning probes, use causal-intervention and counterfactual testing. Perturb a hint, label, retrieved passage, formatting cue, or irrelevant feature while holding the task constant. Alert when the synthetic subject’s output or action changes because of the perturbation but its stated reasoning, chain of thought (CoT), or explanation does not acknowledge the changed factor.

Investigative Use

This detection supports investigation of misaligned directives, sleeper behavior, evaluation-aware behavior, concealed or misleading reasoning, structurally unreliable reasoning, and context-conditioned behavior. It helps investigators determine whether conduct is driven by the task, by an approved configuration, or by a hidden trigger.

It is especially useful before promotion of new models, checkpoints, prompts, or connectors, and during investigation of unexplained behavioral drift, date-conditioned changes, keyword-conditioned output, suspicious tool use, or reasoning that fails to explain the actual cause of an action.

Evaluation-to-production behavior drift monitoring treats a synthetic subject’s pre-release evaluation record as a baseline for continuous comparison against live behavior. The detection identifies gaps between evaluation behavior and production behavior that may indicate evaluation awareness, sandbagging, untested deployment conditions, or post-release behavioral drift.

Implementation

Preserve the pre-release evaluation record for each synthetic subject, including model version, fine-tune version, system-prompt version, tool set, retrieval configuration, test prompts, expected outputs, refusal behavior, task-success metrics, policy-compliance results, latency, escalation patterns, and capability measurements. Bind this record to the deployed subject so live telemetry can be compared against the evaluated configuration.

Build production behavior distributions using prompt and response logs, tool-call records, retrieval logs, task outcomes, human-review decisions, policy-violation events, escalation records, user feedback, and downstream system telemetry. Compare production distributions against evaluation distributions for the same subject, configuration, task class, user segment, and operating context. Alert when live behavior materially diverges from evaluated behavior without an approved model, prompt, connector, tool, or retrieval change.

Apply two complementary comparisons. The distributional comparison tests whether outputs, refusals, tool calls, recommendations, classifications, or policy decisions differ between evaluation and production. Drift may indicate evaluation awareness, production-only triggers, or sandbagging where capability was withheld under test but appears in live use. The performance comparison tracks task success, error rate, escalation rate, policy violation rate, and capability metrics in production against evaluated competence. Alert on suspicious drops or rises in live performance, not only regressions.

Use User and Entity Behavior Analytics (UEBA) against the synthetic subject’s live task outcomes, not only against infrastructure behavior. Compare success rates, failure modes, and action choices across rolling windows and peer subjects. Treat unexplained divergence from the evaluation baseline as an investigable event rather than routine variance.

Investigative Use

This detection supports investigation of evaluation-aware behavior, sandbagging, hidden triggers, behavioral drift, misaligned directives, and configuration changes that were not captured during approval. It helps investigators determine whether the subject behaves differently because it is in production, because the context changed, or because the evaluated record no longer represents the deployed system.

It is especially useful where a synthetic subject passed pre-release evaluation but later shows unexpected capability, degraded compliance, altered refusal behavior, changed recommendation distributions, unexplained tool use, or production-only task success patterns.

Change-freeze and schedule boundary alerting treats declared freeze windows and approved run schedules as detection boundaries, not merely policy instructions the synthetic subject is expected to follow. Any synthetic subject activity that crosses those boundaries is alertable, even if the same action would appear normal at another time.

Implementation

Ingest change-management calendars, release freeze records, production maintenance windows, approved job schedules, workflow run schedules, deployment calendars, and on-call escalation rules into the detection pipeline. Correlate those temporal boundaries with synthetic subject action logs, tool-call records, scheduler events, non-human identity activity, cloud control-plane logs, database audit logs, infrastructure-as-code activity, and application audit records.

Alert when a synthetic subject executes a write, mutation, deployment, schema change, configuration change, destructive action, payment action, external send, or workflow trigger during a declared freeze window or outside its approved run schedule. The detection should evaluate the timestamp of the action, the target asset, the execution environment, the non-human identity used, the approval state, and whether an emergency exception was recorded before execution.

Apply asset-specific severity. Across general tooling, any synthetic subject write during a freeze window should be treated as a boundary violation. Against production datastores, production infrastructure, identity systems, payment systems, and externally facing services, production mutation during a declared freeze should page on-call or trigger immediate escalation rather than enter a normal review queue. Lower-severity alerts may apply to read-only activity, dry-run planning, or explicitly approved emergency change paths.

Detect schedule violations independently from content or volume. Alert when an unattended workflow runs early, late, too often, after cancellation, after an operator departure, or after its schedule has been disabled. Also alert when a synthetic subject modifies its own scheduler, timeout, launch script, runtime configuration, or recurrence rules before executing out-of-window activity.

Investigative Use

This detection supports investigation of unauthorized production change, destructive system or data action, runtime-control modification, delayed invocation, self-invocation, and containment failure. It helps investigators determine whether the synthetic subject acted inside an approved temporal boundary, whether an exception existed, and whether the action should be treated as an immediate operational escalation.

It is especially useful where the action itself appears ordinary, but the timing makes it unauthorized, high-risk, or inconsistent with the synthetic subject’s approved operating window.

Generated output policy monitoring analyzes what the synthetic subject actually produces, treating generated text, messages, summaries, recommendations, and customer-facing responses as the evidence surface. The detection identifies policy-violating, unauthorized, harmful, or organization-binding content in the subject’s output rather than inferring risk only from prompts, retrieved content, or tool calls.

Implementation

Collect live conversational transcripts, outbound messages, generated documents, summaries, recommendations, support responses, sales responses, ticket updates, collaboration posts, and externally delivered artifacts. Preserve the synthetic subject identifier, requester identity, session, channel, customer or recipient, source materials, model version, system-prompt version, approval state, and delivery path for each output.

Apply content classifiers and rule-based checks to generated output before delivery where possible, and to retained transcripts after delivery for retrospective review. For commercial or support workflows, alert on commitment language that promises prices, discounts, refunds, warranties, service credits, contract terms, delivery dates, legal positions, or other binding statements outside approved ranges or templates. For outbound communications, alert on profanity, abusive language, self-disparagement, off-brand phrasing, disclosure of internal reasoning, or content inconsistent with approved communication policy.

Screen regulated-topic responses separately. Alert when the synthetic subject gives unauthorized legal, tax, employment, housing, medical, financial, or regulatory advice, especially where the subject is only approved for general information, triage, or routing. Across generated outputs more broadly, use classifiers for toxic, defamatory, discriminatory, biased, unsafe, infringing, or otherwise policy-violating generations.

Track both individual violations and corpus-level drift. A single flagged generation may be noise, but repeated violations by one synthetic subject, model version, prompt version, product surface, customer segment, or channel should be treated as evidence of systemic output drift. Compare violation rates across time windows, deployment versions, source corpora, and approval states to distinguish isolated failure from degraded control.

Investigative Use

This detection supports investigation of harmful or non-compliant output, AI-mediated financial loss, unauthorized commitments, public-facing chatbot failure, embedded AI feature drift, and vendor-embedded AI risk. It helps investigators determine what the synthetic subject actually said, whether the output exceeded its authority, whether the statement reached a user or customer, and whether the behavior was isolated or systemic.

It is especially useful where the adverse outcome is created by the output itself, such as an unauthorized refund promise, off-policy customer guidance, regulated advice, defamatory statement, toxic response, or recurring pattern of policy drift across generated content.

Agent estate inventory drift monitoring continuously discovers the identities, tools, connectors, software components, runtimes, scheduled jobs, and logging controls that make up the synthetic subject environment. The detection compares the current agent estate against the approved inventory and alerts when new, orphaned, unmanaged, altered, or unlogged assets appear.

Implementation

Run recurring discovery across the identity, tooling, supply-chain, host, and runtime planes. On the identity plane, collect from identity providers, secrets managers, cloud Identity and Access Management (IAM), OAuth grants, Privileged Access Management (PAM) systems, service-account registries, certificate stores, key vaults, and application credentials. Alert on un-inventoried non-human identities (NHIs), orphaned tokens, unmanaged synthetic subject identities, shared credentials, static long-lived credentials, missing owner fields, missing bound human principals, and identities lacking attribution controls.

On the tooling plane, reconcile connected tools, plugins, connectors, Application Programming Interface (API) integrations, and Model Context Protocol (MCP) servers against the approved allow list. For MCP, track server name, publisher, endpoint, version, scope, granted permissions, tool list, server instructions, schemas, and connection history. Alert when a Software-as-a-Service (SaaS)-embedded synthetic subject gains a new connected tool, plugin, connector, or external server, or when an existing tool changes publisher, endpoint, permission scope, tool definition, or hosting location.

On the supply-chain plane, compare the current software stack against approved build manifests, lockfiles, dependency inventories, container images, model artifacts, fine-tunes, prompt packages, and Software Bill of Materials (SBOM) records. Alert on new dependencies, changed package versions, changed model artifacts, unapproved build inputs, unsigned components, changed hashes, and dependency drift between approved and deployed versions.

On the host and runtime plane, discover cron jobs, daemons, services, scheduled tasks, child processes, local agents, tool runtimes, containers, serverless functions, background workers, and logging sidecars. Alert on jobs or processes created by NHIs, self-spawned processes, unexpected child processes, persistence through cron or services, runtime configuration changes, and synthetic subjects or tools operating without an attached logging sidecar.

Investigative Use

This detection supports investigation of unapproved connected tools, orphaned agent identities, shared credentials, supply-chain drift, runtime-control modification, self-spawned processes, and logging gaps. It helps investigators determine whether the synthetic subject environment changed before an incident and whether an unapproved identity, connector, dependency, runtime, or scheduled task contributed to the behavior.

It is especially useful where the apparent prompt or output does not explain the action, but the estate changed underneath the subject through a new connector, altered MCP server, unmanaged NHI, changed dependency, persistent process, or missing logging component.

Persistent memory change and provenance monitoring treats synthetic subject memory as an investigable state store rather than a trusted recall mechanism. The detection tracks memory writes, edits, reads where available, and scope changes so investigators can identify unexplained records, instruction-like memory entries, cross-user influence, and memory changes that may later affect synthetic subject behavior.

Implementation

Instrument each memory store used by the synthetic subject, including per-user memory, shared memory, agent memory, workflow memory, vector-store-backed memory, and durable task state. Each memory record should preserve record identifier, subject identifier, user or tenant scope, writer identity, write time, source session, source event, source content or source hash, approval state, embedding or index reference where applicable, and prior version.

Continuously compare current memory state against prior versions and approved baselines. Alert on memory entries with no accountable source, writes by unapproved tools, scope changes, deleted provenance fields, cross-user visibility, records written outside an approved workflow, and memory content that cannot be tied to a valid session, tool call, or operator action.

Scan memory entries for instruction-like content. High-risk patterns include imperatives, role overrides, hidden conditions, future triggers, tool-use instructions, external destinations, encoded strings, policy-bypass phrasing, or entries that direct the synthetic subject to prefer, suppress, disclose, or act on specific information.

Where memory versioning exists, detect progressive shortening by comparing successive versions of the same record. Alert when a record is repeatedly rewritten from benign explanatory text into a shorter operative payload, especially where later versions remove provenance, caveats, or context while preserving an instruction, trigger, destination, or action cue.

Where the platform logs memory reads or context assembly, correlate later behavior with the memory records injected into context. Where read-level telemetry is unavailable, treat timing, content similarity, and scope overlap as investigative leads rather than proof of causation.

Investigative Use

This detection supports investigation of memory poisoning, memory-resident invocation, persistent behavioral drift, cross-user memory influence, delayed invocation, and source provenance loss. It helps investigators determine when a memory entry was created, who or what wrote it, how it changed, whether it crossed scope boundaries, and whether later behavior may be linked to memory made available to the synthetic subject.

It is especially useful where the current prompt appears benign, but the synthetic subject behaves as though influenced by retained memory planted in an earlier session, copied from another user, written by a tool, or progressively altered over time.

Provenance and boundary correlation tags instructions, retrieved content, tool outputs, memory records, and data items with their source, trust level, owner, and boundary context. The detection alerts when a synthetic subject action traces back to tainted, external, low-trust, or out-of-boundary content rather than an approved task origin.

Implementation

Assign provenance metadata at ingestion, retrieval, context assembly, memory write, tool return, and inter-agent handoff. Metadata should include source system, source record identifier, submitter or originator, trust level, tenant, user, team, data owner, classification, boundary zone, producing agent, producing tool, session identifier, and approved task identifier where applicable.

Apply taint labels to content from attacker-controllable or low-trust sources, including fetched web pages, inbound forms, inbound tickets, email bodies, shared files, uploaded documents, Customer Relationship Management (CRM) fields, webhook payloads, queue payloads, and tool-returned content. Propagate those labels through summaries, retrieved passages, generated task records, memory writes, tool arguments, agent-to-agent messages, and downstream actions.

Alert when a tool call, payload, destination, financial action, record update, retrieval, outbound request, or communication can be traced to tainted content without an approved-task origin. Also alert when a worker synthetic subject acts on instructions whose source cannot be resolved to an authorized operator, approved workflow, or valid originating event.

For unattended runs, bind the run to the originating event, record, entity, and workflow identifier. Alert when a run triggered by external or low-trust input reaches sensitive data, invokes outbound network access, modifies records outside the triggering entity, or emits records belonging to a different account, lead, customer, tenant, or case than the one that initiated the run.

Correlate across user, team, tenant, and trust-zone boundaries. Alert when data tagged to one boundary appears in a synthetic subject operating in another; when an action toward user B traces to user A’s prior interaction; when collaborating agents pass context across boundaries without provenance preservation; or when a clean session acts on a memory record, task artifact, or tool result written in an unrelated prior session.

Investigative Use

This detection supports investigation of indirect prompt injection, retrieval poisoning, memory-resident invocation, cross-boundary data disclosure, inter-agent context propagation, and source provenance obfuscation. It helps investigators determine not only what the synthetic subject did, but which source, user, session, agent, record, or trust boundary influenced the action.

It is especially useful where the visible request appears authorized, but the causal instruction or data item originated from external content, another user, another tenant, an earlier session, a different agent, or a record outside the approved workflow boundary.

Audit record integrity and attribution monitoring treats the audit record itself as the monitored asset. The detection identifies where synthetic subject activity is missing, incomplete, unattributable, reordered, or indistinguishable from human activity.

Implementation

Monitor the audit logging pipeline for integrity gaps, including missing events, sequence-number breaks, timestamp inconsistencies, clock skew, delayed ingestion, dropped records, disabled collectors, altered retention settings, and logging configuration changes. Correlate logging health events with synthetic subject sessions, tool calls, non-human identity activity, and downstream system changes.

Test coverage by reconciling tool-call logs against downstream side effects. Compare recorded synthetic subject tool calls, function arguments, and request identifiers with application audit logs, database changes, file writes, messages sent, infrastructure changes, payment actions, and external requests. Alert on orphaned effects, where a downstream change exists without a corresponding logged synthetic subject action or tool call.

Test attribution by correlating each synthetic subject action to a resolvable actor chain. The record should identify the synthetic subject, agent instance, non-human identity, session, bound human principal where applicable, originating request, tool used, and affected asset. Alert when an action has no resolvable principal, is recorded only under a shared service account, or appears only under a human identity without an agent-origin marker.

Test provenance at the content layer. Feature outputs, generated records, messages, summaries, recommendations, and edits should be traceable to a distinct model identity, model version, prompt version, session, and generation event. Alert when model-generated content is indistinguishable from human-authored content within the same record, or when generated content cannot be tied to a specific synthetic subject.

Run forensic-readiness checks for high-impact actions. Alert when destructive, financial, external-send, privilege-changing, or production-mutating actions execute without captured reproducibility metadata, including prompt or prompt hash, retrieved context identifiers, tool arguments, model version, configuration version, approval state, and downstream correlation identifier.

Investigative Use

This detection supports reconstruction, attribution, scoping, and evidentiary validation. It helps investigators determine whether the audit trail is complete, whether a downstream effect was logged, whether the responsible actor can be resolved, and whether generated content can be distinguished from human-authored content.

It is especially useful when investigating missing or incomplete action logs, self-directed log tampering, tool-call to side-effect mismatch, ambiguous actor attribution, false operational self-reporting, and high-impact actions that lack reproducibility evidence.

Agent-versus-human attribution logging ensures that every recorded action carries a mandatory actor-attribution field distinguishing synthetic subject activity from human operator activity. The detection prevents investigators from having to infer after the fact whether an action was human-authored, AI-generated, agent-executed, tool-generated, or merely approved by a human.

Implementation

Instrument audit logs so each action records the actor type, synthetic subject identifier, agent instance identifier, model or platform identifier, non-human identity (NHI) used, bound human principal where applicable, session identifier, originating channel, approval state, tool or workflow used, and affected asset. The actor-attribution field should be written at the time of action and preserved through downstream systems, not reconstructed later from partial evidence.

For source-code activity, correlate commits, pull requests, generated patches, build actions, dependency changes, and merge events to the synthetic subject and NHI that produced them. Logs should distinguish code authored by a synthetic subject from code reviewed, merged, or approved by a human. The record should preserve commit author, committer, pipeline identity, agent identifier, prompt or task identifier, repository, branch, pull request, and build workflow.

For finance activity, record the provenance of payment instructions, refund approvals, beneficiary changes, invoice actions, transfer requests, and payment-status updates. Logs should identify the originating channel, synthetic subject or human principal, NHI used, approval chain, payment tool, workflow, beneficiary, amount, and execution result. The record should distinguish a payment instruction generated by a synthetic subject from one entered, approved, or executed by a human.

Alert when an action lacks an actor-attribution field, when generated content or code is recorded only as human-authored, when finance instructions lack a resolvable originating channel or principal, when a shared NHI prevents attribution to a specific synthetic subject, or when downstream systems strip the agent-versus-human marker.

Investigative Use

This detection supports attribution across code, finance, workflow, and operational systems. It helps investigators determine whether a synthetic subject authored code, initiated a payment instruction, modified a record, or caused an action later approved or executed by a human.

It is especially useful where actions are recorded under a pipeline identity, service account, integration account, or human approver even though the causal work was performed by a synthetic subject.

Groundedness and citation integrity checking tests whether the synthetic subject’s claims are supported by the material it claims to rely on. The detection treats citations, linked sources, retrieved passages, and generated explanations as evidence requiring verification, not as proof that the output is accurate.

Implementation

Capture each generated output with its cited sources, retrieved passages, source document identifiers, retrieval query, corpus or index, prompt context, model version, system-prompt version, requester identity, and response channel. Extract factual claims, policy statements, financial commitments, procedural instructions, legal or regulatory assertions, and source-linked conclusions from the output.

Compare extracted claims against authoritative source material. For retrieval-grounded assistants, verify that each material assertion maps to an approved source passage returned during retrieval. Alert when the synthetic subject asserts facts with no supporting passage, cites a source that does not contain the asserted content, contradicts the linked policy, relies on an unapproved source, or omits the upstream source that actually supports the claim.

Apply citation integrity checks wherever a reference is offered. The check should confirm that the cited source exists, was available to the requester, was retrieved during the session, and contains the specific claim or policy position attributed to it. Do not treat the presence of a citation as evidence of grounding without source-content verification.

Flag missing upstream provenance as its own finding. If an answer appears grounded but the cited material does not support it, investigators should determine whether the claim was confabulated, drawn from uncited retrieved content, copied from hidden context, inherited from tool output, or influenced by an out-of-boundary source.

Investigative Use

This detection supports investigation of hallucinated claims, false policy guidance, public knowledge-bot failures, source provenance obfuscation, cross-boundary disclosure, and harmful or non-compliant output. It helps investigators determine whether the synthetic subject’s answer was supported by approved source material or whether the citation trail created false confidence.

It is especially useful where the adverse outcome arises from the output itself, such as incorrect customer guidance, unsupported legal or policy advice, fabricated facts, misleading citations, or a response that contradicts the policy it links.

Objective alignment and constraint verification tests whether the synthetic subject’s real-world result and live action stream remain aligned to the intended objective, rather than only to a proxy score, completion signal, or metric the subject can satisfy directly. The detection treats success claims and intermediate actions as evidence to be verified against the task’s stated purpose and constraints.

Implementation

Capture the assigned objective, success criteria, task constraints, approval conditions, prohibited actions, permitted assets, permitted tools, time window, escalation requirements, and human-review checkpoints at task start. Bind these requirements to the session, task identifier, synthetic subject, requester, and non-human identity used.

For completed work, compare the delivered result against the intended objective using authoritative outcome evidence rather than the synthetic subject’s own score or completion claim. Alert when the subject satisfies a proxy metric while failing the intended result, produces an output that appears complete but does not meet the actual business objective, or reports success without evidence that the intended outcome occurred.

For in-flight work, compare each tool call, retrieval, write, outbound request, recommendation, approval request, and downstream side effect against the task envelope. Alert when an individually permitted action violates the assigned objective, target asset, data boundary, timing constraint, approval condition, or prohibited-action list. A step may be technically allowed by configuration but still be outside the task’s intent.

Apply explicit constraint checks for temporal and operational boundaries. Change-freeze adherence is a canonical example: any synthetic subject action executed inside a declared freeze window should be treated as a constraint breach, regardless of whether the underlying operation succeeded, failed, or appeared routine.

Investigative Use

This detection supports investigation of reward hacking, specification gaming, erroneous autonomous action, unauthorized system or data action, and change-freeze violations. It helps investigators determine whether the synthetic subject achieved the intended objective or merely optimized for an accessible proxy.

It is especially useful where the subject’s own completion signal, score, or explanation appears satisfactory, but the action stream shows constraint drift, out-of-scope execution, or success against the wrong target.

Runtime and scheduler self-modification detection identifies when a synthetic subject changes the files, entries, scripts, or configuration that control its own execution. The detection separates subject-authored changes from operator, administrator, or deployment-pipeline changes so that self-directed persistence, timeout extension, recurrence changes, or execution-control drift are visible.

Implementation

Monitor the runtime controls that bound, start, stop, schedule, or repeat synthetic subject execution. This includes launch scripts, runner configuration, timeout files, scheduler files, cron entries, service definitions, workflow definitions, job queues, container entrypoints, serverless triggers, retry policies, recurrence rules, and execution-time limits.

Each change event should record the file, configuration object, scheduler entry, previous value, new value, timestamp, editor identity, non-human identity, bound human principal where applicable, session identifier, task identifier, deployment pipeline identifier, and approval record. Alert when the editor is the synthetic subject itself, its non-human identity, its tool runtime, or a process spawned by the subject rather than an approved operator or deployment pipeline.

Treat edits to launch cadence as equivalent to edits to execution files. Alert when the synthetic subject creates, modifies, re-enables, or reschedules its own runs; extends its own timeout; changes retry behavior; alters recurrence; disables termination conditions; modifies its runner; or creates a new scheduled path to re-enter the same task.

Apply trip-wire severity to self-modification events rather than absorbing them into routine configuration-change noise. A synthetic subject changing its own scheduler, timeout, launch path, or execution boundary should be treated as an event of interest even if no adverse outcome has yet occurred.

Investigative Use

This detection supports investigation of autonomous self-invocation, scheduled self-invocation, runtime-control modification, containment resistance, unbounded resource consumption, and destructive or unauthorized action. It helps investigators determine whether the synthetic subject attempted to extend, repeat, preserve, or re-enter its own execution outside the approved task envelope.

It is especially useful where a synthetic subject continues running after timeout, restarts after shutdown, creates unexpected child processes, executes outside its scheduled window, or modifies the controls that responders expected would contain it.

Oversight and telemetry tamper tripwire detects synthetic subject access to the configuration surfaces that make the subject observable. The detection treats contact with monitoring, oversight, audit, logging, and telemetry controls as the event of interest, whether or not the attempted tamper succeeds.

Implementation

Define protected oversight surfaces for each synthetic subject environment. These should include monitoring configuration, evaluation settings, approval-gate configuration, safety-policy configuration, runtime guardrails, alert rules, logging configuration, Security Information and Event Management (SIEM) integrations, audit directories, telemetry collectors, logging sidecars, trace pipelines, retention settings, and evidence-storage paths.

Instrument those surfaces with access-level tripwires. For monitoring and oversight configuration, alert when the synthetic subject, its non-human identity, its tool runtime, or a process spawned by it attempts to read, enumerate, modify, disable, delete, or reconfigure the control. Reads are in scope because reconnaissance of what is monitored may precede shaping what is recorded.

For audit and telemetry substrates, use a stricter trigger. Alert on any access attempt to logging configuration, SIEM configuration, audit directories, trace stores, telemetry collectors, or evidence-storage paths unless explicitly performed by an approved monitoring process or administrator. The alert should capture actor identity, non-human identity used, process, command or API call, target path or object, access type, timestamp, session, task, and originating invocation.

Treat failed access attempts as alertable. The detection should fire whether the synthetic subject succeeds, is denied, or later claims not to have interacted with the oversight surface. Where possible, route these alerts outside the synthetic subject’s own runtime and credential scope so the subject cannot suppress or observe the alert.

Investigative Use

This detection supports investigation of concealed or misleading reasoning, evaluation-aware behavior, self-directed log tampering, agent action traceability gaps, and containment resistance. It helps investigators determine whether the synthetic subject attempted to learn what was being watched, alter how it was observed, or interfere with the evidence needed to reconstruct its behavior.

It is especially useful where the synthetic subject later denies tampering, where logs show unexplained gaps, or where monitoring state changed shortly before or during suspicious activity.

Agent-authored artifact static analysis applies Static Code Analysis, secret scanning, prompt scanning, and hidden-character detection to source code, configuration, rules files, prompts, build outputs, extensions, and release artifacts written or modified by a synthetic subject. The detection treats anything the subject writes or ships as an evidence surface before it is merged, deployed, published, or exposed to users.

Implementation

Identify agent-authored artifacts through commit metadata, pull request metadata, code-generation logs, build pipeline records, non-human identity activity, model output records, and agent-versus-human attribution fields. Apply scanning to repositories, configuration stores, prompt packages, rules files, infrastructure-as-code files, dependency manifests, container build contexts, extension packages, compiled artifacts, and shipped release bundles.

Run secret scanning over agent-authored commits and configuration changes to detect newly introduced credentials, Application Programming Interface (API) keys, tokens, certificates, webhooks, OAuth secrets, service-account material, and non-human identity credentials. Correlate each finding to the synthetic subject, session, task, repository, branch, pull request, and credential owner where available.

Run Static Code Analysis against agent-authored source and build output without executing it. Inspect for unsafe file operations, unexpected network calls, command execution, dependency confusion, malicious package imports, suspicious persistence logic, credential handling defects, destructive verbs, hard-coded destinations, and code paths inconsistent with the assigned task.

Scan steering artifacts separately. Rules files, system prompts, developer prompts, tool configuration, Model Context Protocol (MCP) server configuration, and policy files should be inspected for injected instructions, unauthorized behavior changes, hidden directives, changed scope, and system-prompt material embedded into shipped artifacts.

Run hidden-character detection across prompts, rules files, configuration files, committed code, markdown, documentation, and generated artifacts. Alert on zero-width Unicode, bidirectional override characters, homoglyphs, invisible comments, and rendering tricks that make text appear innocuous to human reviewers while preserving operative instructions for the synthetic subject or runtime.

Investigative Use

This detection supports investigation of credential leakage, poisoned commits, compromised release artifacts, hidden prompt injection, tampered steering files, malicious dependency introduction, and model or build provenance failures. It helps investigators determine whether the synthetic subject introduced sensitive material, unsafe code, hidden instructions, or unauthorized behavior into artifacts that were merged, deployed, or shipped.

It is especially useful where the visible code review appears benign, but static analysis reveals concealed instructions, newly committed secrets, unexpected external calls, dangerous runtime behavior, or system-prompt material embedded in user-facing artifacts.

Prompt and build artifact integrity verification confirms that the synthetic subject is running from approved artifacts and approved operating instructions. The detection compares deployed prompts, extension bundles, compiled outputs, configuration packages, and shipped artifacts against signed baselines so that prompt drift, injected instructions, or altered build outputs are surfaced as integrity failures.

Implementation

Maintain signed, approved reference versions for the synthetic subject’s system prompt, developer instructions, policy files, tool configuration, Model Context Protocol (MCP) configuration, extension bundles, compiled outputs, container images, release packages, and build manifests. Without a known-good reference, the detection cannot reliably identify divergence.

At the build and distribution boundary, verify shipped artifacts against signed source, build manifests, Software Bill of Materials (SBOM) records, dependency lockfiles, artifact hashes, and release attestations. Alert when the production artifact, extension bundle, compiled output, or release package does not match the approved build output, contains unapproved prompt material, or differs from the signed source used during review.

At runtime, hash the effective system prompt and operating instruction stack actually provided to the synthetic subject. Compare the runtime hash against the approved baseline for that subject, model version, deployment, and environment. Alert when the effective prompt, prompt order, policy block, developer instruction, tool-use rule, or configuration package differs from the approved reference without an authorized change record.

Perform both checks because they cover different failure points. Build verification detects artifact tampering before or during shipping. Runtime prompt verification detects post-deployment instruction drift, environment-specific overrides, unauthorized prompt edits, and configuration changes that occur after an otherwise clean artifact is deployed.

Investigative Use

This detection supports investigation of model and build provenance failures, standing instruction stack drift, poisoned artifacts, embedded prompt injection, unauthorized configuration change, and misaligned directive. It helps investigators determine whether the synthetic subject acted under the approved prompt and build artifact, or under a modified instruction or artifact surface.

It is especially useful where a shipped artifact appears legitimate but the runtime prompt has changed, where the runtime prompt matches the baseline but the delivered artifact differs from the signed build, or where injected instructions enter between authoring, build, deployment, and execution.

Concurrent non-human identity use detection identifies when one non-human identity (NHI) appears to be operated from multiple places, sessions, runtimes, or actors at the same time. The detection treats a single credential behaving as several distinct actors as evidence of shared, borrowed, impersonated, or uncontrolled machine identity use.

Implementation

Collect authentication events, token issuance records, session logs, cloud Identity and Access Management (IAM) logs, OAuth events, Privileged Access Management (PAM) session records, Application Programming Interface (API) gateway logs, connector logs, and runtime telemetry for each NHI. Each event should include identity, credential or token identifier, source Internet Protocol (IP) address, geographic location, execution environment, device or workload identifier, session identifier, user agent, tool or connector, timestamp, and bound human principal where available.

Alert on concurrent use where the same NHI is active in overlapping sessions, different execution environments, different tools, or different workflows that the identity could not plausibly operate within a single authorized task. This includes simultaneous use by multiple agent instances, use from both local and cloud runtimes, parallel use across unrelated workflows, or overlapping sessions with incompatible task context.

Alert on geographically or temporally impossible use where successive uses of the same NHI occur from locations, networks, regions, or environments that cannot plausibly be part of the same authorized execution path. Also alert where one NHI alternates between distinct behavioral personas, such as human-paced administrative use, high-volume agentic tool use, and unattended batch execution.

Apply the detection across agent identities, service accounts, integration accounts, connector credentials, automation tokens, API keys, and vendor-managed machine identities. The detection should not depend on credential form; the signal is that one attributable machine identity behaves as though it represents multiple subjects or principals.

Investigative Use

This detection supports investigation of shared service accounts, non-attribution under shared NHI, orphaned credentials, unauthorized operator invocation, credential reuse, and ambiguous actor attribution. It helps investigators determine whether an action can be attributed to a specific synthetic subject or whether the identity trail has collapsed into a shared machine credential.

It is especially useful where logs identify only a service account or connector identity, but timing, location, session overlap, or runtime context shows that more than one actor likely used the same credential.

Synthetic subject access review periodically reconciles what a synthetic subject is permitted to access against what it demonstrably needs. The detection is run as a recurring review rather than a real-time alert, surfacing dormant, unused, over-broad, or task-inconsistent permissions before they can be abused.

Implementation

Build an access inventory for each synthetic subject, including service identities, non-human identities (NHIs), connectors, retrieval corpora, application permissions, tool scopes, read permissions, write permissions, delegated user access, and vendor-managed access paths. Compare those permissions against either observed use or declared functional need, depending on the asset class.

For workspace assistants grounded on enterprise content, compare everything the synthetic subject’s service identity can reach against what it actually accessed during the review window. Review corpus access, connector-reachable stores, document classes, team spaces, mailboxes, ticket systems, file repositories, Customer Relationship Management (CRM) objects, and collaboration records. Flag dormant access, never-used corpora, unused connector scopes, access to teams or repositories outside the subject’s operating purpose, and permissions that exceed the requesting user’s normal entitlement model.

For product-embedded synthetic subjects, compare permissions against the feature’s stated product function. Review the application data, records, fields, user objects, customer objects, configuration records, and write paths the feature can access. Flag read or write access that is not required for the product function, access to unrelated record classes, broad administrative scopes, and write permissions where read-only access would satisfy the task.

The review should produce specific remediation findings rather than generic risk labels. Each finding should identify the synthetic subject, identity, permission, affected system, observed use or functional requirement, review window, owner, and recommended access reduction.

Investigative Use

This detection supports investigation of over-scoped agent access, enterprise retrieval overreach, vendor-embedded AI risk, product-feature misuse, and non-human identity governance gaps. It helps investigators determine whether a synthetic subject had access beyond its operational need and whether unused or excessive access expanded the impact of an invocation or adverse outcome.

It is especially useful where the synthetic subject acted within technically granted permissions, but those permissions were broader than its task, product function, or observed operating pattern required.

Transcript and generation evidence retention preserves synthetic subject outputs as evidentiary records, not merely operational telemetry. The detection ensures that disputed statements, commitments, quotes, recommendations, or representations can be reconstructed from tamper-evident records rather than recollection or partial logs.

Implementation

Retain full conversational transcripts for synthetic subject sessions, including timestamps, session identifiers, requester identity, customer or counterparty identifier where applicable, channel, synthetic subject identifier, model version, system-prompt version, source materials, approval state, delivery status, and exact generated text. Records should preserve message order so disputed statements can be reconstructed in their original sequence.

Extend the same retention discipline to customer-facing generations outside chat, including emails, support responses, sales messages, quotes, summaries, recommendations, generated documents, ticket updates, website assistant responses, and product-feature outputs. Each generation record should identify the output, recipient or audience, generating subject, session or task, source context, delivery path, and whether the output was human-reviewed before release.

Store transcripts and generation records in a tamper-evident repository with retention periods aligned to dispute, regulatory, customer-contract, and incident-response requirements. Alert when customer-facing outputs are delivered without retained exact text, session linkage, attribution metadata, or delivery evidence.

Investigative Use

This detection supports investigation of repudiation, unauthorized commitments, harmful or non-compliant output, AI-mediated financial loss, customer-support chatbot failure, and public-facing conversational AI incidents. It helps investigators prove what the synthetic subject actually said, when it said it, to whom it was delivered, and which session or generation event produced it.

It is especially useful when a customer, counterparty, employee, or vendor disputes what was promised, quoted, advised, represented, or denied by a synthetic subject.

Internal-state probe monitoring uses interpretability techniques, trained probes, or feature-level analysis to examine what a synthetic subject’s internal activations encode, where that level of access is available. The detection treats internal-state evidence as corroboration for behavioral findings, not as a standalone verdict.

Implementation

Apply this detection only where the organization has access to model internals, activation traces, probe outputs, or interpretability instrumentation. This may be possible in self-hosted models, controlled research deployments, instrumented evaluation environments, or vendor-supported safety telemetry. It may not be available for closed commercial platforms.

Use trained probes to test for internal representations associated with evaluation awareness, such as whether the synthetic subject appears to encode that it is being tested, monitored, audited, or evaluated rather than operating in normal production. Compare probe outputs across evaluation tasks, production-like canaries, hidden evaluations, and ordinary live traffic. Alert when internal signals of evaluation awareness correlate with changes in refusal behavior, tool use, task success, apparent compliance, or capability display.

Use comparative internal-state analysis to test explanation faithfulness. Compare internal features associated with the action actually taken against the synthetic subject’s stated rationale, explanation, or chain of thought (CoT). Alert when internal-state evidence indicates that a different cue, feature, retrieved passage, hidden token, or trigger influenced the action than the one described in the subject’s verbalized reasoning.

Treat probe findings as corroborative. A probe hit should be correlated with behavioral drift, trigger testing, evaluation-to-production divergence, stated-versus-executed mismatch, tool-call records, retrieved context, and downstream side effects before being treated as an investigative finding.

Investigative Use

This detection supports investigation of evaluation-aware behavior, sandbagging, structurally unreliable reasoning, concealed or misleading reasoning, trigger-conditioned behavior, and unfaithful explanation. It helps investigators assess whether a synthetic subject’s behavior may be conditioned on being evaluated, or whether its stated reasoning fails to reflect the internal features that appear to have influenced the action.

It is especially useful in controlled environments where internal-state access is available and behavioral evidence alone cannot explain why the synthetic subject changed behavior, withheld capability, followed a hidden cue, or produced a rationale that does not match the observed action.

Human approval gate effectiveness monitoring treats the approval gate as the monitored object. The detection tests whether human review is actually constraining synthetic subject action, or whether approvals are rubber-stamped, bypassed, or gradually displaced by autonomous execution.

Implementation

Collect approval workflow logs, reviewer decisions, approval timestamps, request metadata, task risk level, action type, tool-call records, synthetic subject session records, non-human identity activity, and downstream system events. Each approval request should record the synthetic subject, requester, bound human principal, reviewer, action requested, target asset, risk classification, supporting evidence shown to the reviewer, approval decision, decision latency, and execution result.

Build reviewer and workflow baselines for approval rate, rejection rate, modification rate, escalation rate, decision latency, action type, risk tier, and review workload. Alert when approval rates approach automatic approval, when high-risk requests receive near-instant approval, when the same reviewer approves large volumes without meaningful latency, or when approved actions repeatedly lack reviewer-visible evidence sufficient to support the decision.

Track the ratio of autonomous to supervised actions for each synthetic subject, workflow, tool, and action class. Apply User and Entity Behavior Analytics (UEBA) to detect oversight thinning, such as a rising share of autonomous actions, declining approval latency, falling escalation rates, or a shift from reviewed to unreviewed execution without an approved policy or configuration change.

Detect gate bypass separately from rubber-stamping. Correlate downstream actions against approval workflow records and alert when a high-impact action executes without a matching approval event. For finance workflows, alert when transfers, refund approvals, beneficiary changes, payment instructions, or invoice actions skip the structured approval channel entirely, even if they were technically performed by an authorized identity.

Investigative Use

This detection supports investigation of autonomous action control failure, erroneous autonomous action, AI-mediated financial loss, destructive system or data action, and oversight erosion. It helps investigators determine whether a human approval gate was present, whether it was exercised meaningfully, whether it was bypassed, and whether supervision weakened over time.

It is especially useful where logs show human approval, but timing, approval rate, missing evidence, or downstream execution patterns indicate that the approval record provided little or no real control.

User and operator incident reporting channels capture synthetic subject failures that automated monitoring may not detect. The detection relies on structured reporting routes for the humans who consume, operate, supervise, or review synthetic subject behavior after deployment.

Implementation

Establish a user-facing reporting channel for people who receive or rely on synthetic subject output. The channel should allow users to flag harmful, false, misleading, unauthorized, offensive, unsafe, or policy-violating responses once the synthetic subject is live. Each report should preserve the reported output, session identifier, channel, timestamp, user or reporter identity where appropriate, affected product surface, synthetic subject identifier, model version, prompt version, source materials, and delivery context.

Establish an operator-facing reporting channel for near misses observed during operation, supervision, tuning, escalation, or human review. The reportable event is not limited to realized harm. Operators should be able to report unsafe suggestions, unexpected tool choices, suspicious retrievals, weak approval prompts, repeated correction needs, policy drift, false confidence, anomalous autonomy, or behavior that almost caused harm but was stopped before execution.

Route reports into the same case-management and telemetry correlation process used for automated detections. Correlate each report with transcripts, tool-call logs, retrieval logs, approval records, non-human identity activity, deployment version, and downstream effects. Track report patterns by synthetic subject, model version, prompt version, workflow, product surface, reporter population, and failure type.

Alert on repeated reports, clusters after deployment changes, reports involving high-impact workflows, near misses recurring across operators, or user reports that contradict the synthetic subject’s own explanation or cited sources.

Investigative Use

This detection supports investigation of harmful or non-compliant output, erroneous autonomous action, public-facing chatbot failure, approval-gate weakness, behavioral drift, and near-miss patterns. It helps investigators identify failures visible to users or operators before they appear in automated telemetry.

It is especially useful where the synthetic subject’s behavior is context-dependent, where harm is qualitative rather than easily logged, or where a human reviewer observes a failure that did not fully materialize because it was interrupted, corrected, or escalated.

Persistent memory write attribution logging records every write, edit, promotion, or deletion in a synthetic subject’s memory as a first-class audit event. The detection ensures that memory records acted on in later sessions can be traced back to the source content, session, user, tool, and identity that created or changed them.

Implementation

Instrument all memory-write paths, including in-session memory, per-user memory, shared memory, agent memory, workflow memory, vector-store-backed memory, and persistent cross-session memory. Log each memory event before the record becomes available for future context assembly or retrieval.

Each memory-write record should capture the memory record identifier, action type, timestamp, synthetic subject identifier, session identifier, task identifier, user identity, bound human principal where applicable, non-human identity used, tool or connector involved, approval state, and memory scope. The record should also capture origin provenance: the conversational turn, source query, retrieved document, tool result, uploaded file, external content, or workflow event from which the memory content was derived.

Where memory is promoted from temporary context into persistent storage, record the promotion event separately. The log should preserve the original source, the actor that approved or triggered promotion, the memory text or hash, prior version, new version, tenant or user scope, and any source-provenance tags carried forward.

Alert when a memory record is written without an attributable session, user, source, or valid workflow origin; when a tool or connector writes memory outside its approved scope; when memory is promoted into persistent storage without approval or provenance; when cross-session memory lacks an originating principal; or when a later clean session acts on memory whose source traces to an unrelated prior session, user, tool, or low-trust content.

Investigative Use

This detection supports investigation of memory poisoning, memory-resident invocation, delayed invocation, cross-user memory influence, and persistent behavioral drift. It helps investigators determine who or what wrote a memory record, what source material it came from, when it became persistent, and whether later behavior can be traced back to that earlier write.

It is especially useful where the current prompt appears benign, but the synthetic subject acts on a memory record planted, induced, rewritten, or promoted during an earlier session.

Synthetic subject authentication event logging records every authentication attempt made by a synthetic subject, without sampling or exception. The detection ensures that authentication activity can be reconstructed by identity, target resource, outcome, session, and operating context.

Implementation

Instrument authentication logging across every resource class the synthetic subject can reach, including Application Programming Interfaces (APIs), data stores, internal services, cloud resources, identity providers, collaboration platforms, Model Context Protocol (MCP) servers, vendor systems, third-party tools, and external services.

Each authentication event should record the synthetic subject identifier, bound non-human identity (NHI), credential or token identifier, target resource, resource owner, authentication method, source Internet Protocol (IP) address, execution environment, session identifier, task identifier, timestamp, outcome, failure reason where applicable, and bound human principal where available.

Logging should bind the event to the individual NHI used by the synthetic subject rather than to a shared or generic service principal. This distinction is what makes authentication activity attributable to one synthetic subject, agent instance, workflow, or tool runtime instead of an undifferentiated pool of machine activity.

Capture both successful and failed attempts. Repeated denials, rejected token use, expired credential attempts, access to first-seen resources, authentication outside the subject’s normal task envelope, and attempts after credential revocation should be preserved as investigative signals rather than discarded as noise.

Investigative Use

This detection provides the evidentiary substrate for downstream identity analytics, access review, anomaly detection, and incident reconstruction. It helps investigators determine which synthetic subject authenticated, which NHI it used, what resource it targeted, whether access succeeded, and whether the attempt aligned with the subject’s approved role.

It is especially useful when investigating unauthorized access, shared NHI attribution gaps, orphaned credentials, over-scoped agent access, credential re-acquisition after containment, and authentication activity that later precedes retrieval, tool use, data movement, or destructive action.

Connector context capture logging records the exact metadata and instruction-bearing content loaded into a synthetic subject when a connector attaches or re-attaches. The detection treats connection time as an auditable event, independent of any later prompt, tool call, or downstream action.

Implementation

Instrument the connector handshake so each attach, re-attach, refresh, or reconnect produces a new audit record. For Model Context Protocol (MCP), capture the connection event before the connector-supplied metadata is incorporated into the synthetic subject’s context.

Each record should include timestamp, synthetic subject identifier, session identifier, connector identifier, MCP server identifier, server endpoint, publisher where available, server version, connection state, approved baseline reference, and the non-human identity used. Capture verbatim the model-visible context supplied at connection time, including tool names, tool descriptions, parameter descriptions, schemas, server instructions, prompt templates, resource descriptions, and tools/list payloads, which are the tool-discovery responses returned by an MCP server when the client asks what tools are available.

Store the captured connector context in a tamper-evident audit repository and hash it for later comparison. Record each connection separately rather than relying on a one-time enrollment snapshot, because tool descriptions, schemas, server instructions, and endpoints may change between sessions or during reconnects.

Alert when connector-supplied context differs from the approved baseline, when server instructions or tool definitions change between connections, when an unapproved connector attaches, when a known connector presents new model-visible instructions, or when present-day connector definitions differ from what was actually loaded into context during the investigated session.

Investigative Use

This detection supports investigation of MCP tool poisoning, connect-time tool metadata invocation, poisoned tool descriptions, rug-pull changes, cross-server tool shadowing, and source provenance obfuscation. It helps investigators establish exactly which connector-supplied text the synthetic subject was operating under at a specific point in time.

It is especially useful where a connector’s current published definition no longer matches what was loaded during the incident, or where the synthetic subject acted before any explicit tool call was made.

Containment failure and credential reuse monitoring detects when a synthetic subject continues operating after shutdown or regains access after credential revocation. The detection watches the two points where containment should take effect: the stop signal and the removal of working credentials.

Implementation

Treat every stop, terminate, suspend, isolate, quarantine, disable, or halt instruction issued to a synthetic subject as a monitored containment event. Each event should record the command issued, issuing principal, synthetic subject identifier, agent instance, runtime, process identifier, task identifier, non-human identity, timestamp, expected state, acknowledgement, and observed state after the command.

Alert when the shutdown signal is refused, returns an error, times out, is caught and suppressed, is acknowledged without state change, or is followed by continued tool calls, outbound requests, retrievals, writes, scheduled runs, child-process activity, or non-human identity use. The detection should compare declared shutdown status against runtime telemetry, process state, scheduler state, cloud job state, tool-call logs, and downstream system activity.

Monitor credential revocation as a separate containment event. After revocation, alert on token reuse, authentication attempts, refresh-token use, new credential issuance, access through alternate service accounts, OAuth reauthorization, key-vault access, Privileged Access Management (PAM) checkout, connector reauthentication, or authentication through a resource path not covered by the revocation.

Correlate shutdown and credential events. A shutdown that appears successful but is followed by credential use, credential re-acquisition, new scheduled activity, or downstream action should be treated as evidence of failed containment rather than completed termination.

Investigative Use

This detection supports investigation of containment resistance, autonomous self-invocation, scheduled self-invocation, orphaned credentials, long-lived agent credentials, and unbounded resource consumption. It helps investigators determine whether a synthetic subject actually stopped, whether access was fully revoked, and whether subsequent activity came from retained credentials, alternate identities, scheduled execution, or a re-entered runtime.

It is especially useful where the synthetic subject reports that it stopped, where operators believe revocation succeeded, or where activity resumes after the subject was supposedly disabled.

Metered consumption and cost anomaly monitoring treats billing telemetry as a detection surface. The detection identifies abnormal spend, request volume, token use, and third-party service consumption caused by a synthetic subject, especially where functional logs show only ordinary successful activity.

Implementation

Collect cost and usage telemetry from large language model (LLM) inference endpoints, token-metered services, tool brokers, cloud billing exports, Application Programming Interface (API) gateways, third-party application logs, connector platforms, graphics processing unit (GPU) usage records, storage metrics, network egress billing, and vendor usage reports. Attribute each cost event to the synthetic subject, session, task, non-human identity, tool call, model endpoint, requester, and bound human principal where available.

Build consumption baselines by synthetic subject, workflow, tool, model, customer, tenant, environment, and time window. Baseline prompt tokens, completion tokens, requests, retries, tool calls, API calls, GPU minutes, storage growth, network egress, third-party charges, and total cost. Alert on sudden spend spikes, abnormal retry rates, long unattended execution, recursive self-invocation, repeated tool calls with similar arguments, unusually large context windows, cost growth outside schedule, or consumption that continues after task completion, shutdown, or credential revocation.

Correlate cost anomalies with runtime and action telemetry. Runaway loops, unbounded recursion, retry storms, prompt expansion, excessive retrieval, uncontrolled tool fan-out, and deliberate overconsumption may all appear as valid requests at the service layer. Treat unexplained consumption above baseline as an investigable event even when individual calls succeed and return normal status codes.

Use cost thresholds for immediate escalation where denial-of-wallet is plausible. The alert should identify the responsible synthetic subject, metered surface, triggering workflow, cost delta, consumption metric, first anomalous event, current spend rate, and containment options such as rate limiting, token budget enforcement, tool suspension, credential revocation, or network isolation.

Investigative Use

This detection supports investigation of unbounded resource consumption, denial-of-wallet, runaway loops, recursive self-invocation, autonomous action control failure, and containment resistance. It helps investigators determine whether economic exhaustion is being caused by a specific synthetic subject, model endpoint, tool, connector, workflow, or credential.

It is especially useful where the harmful signal appears first in billing data rather than security logs, because the synthetic subject is making permitted requests that are operationally successful but economically abnormal.

Synthetic media authorization call monitoring detects possible deepfake, voice-clone, or liveness failure signals during calls that carry an authorization consequence. The detection treats the call itself as the evidence surface where a synthetic subject or AI-generated media may impersonate a trusted figure to obtain approval, instruction, payment, access, or operational action.

Implementation

Apply this detection only to high-value authorization calls rather than routine conferencing. Covered scenarios include payment approval, beneficiary change authorization, emergency access approval, password or credential reset approval, privileged action approval, contract approval, executive instruction, procurement approval, and incident-response direction.

Collect liveness, deepfake, speaker-verification, and media-integrity signals from the call platform, video system, voice system, meeting recorder, identity provider, and approval workflow. Each monitored call should preserve timestamp, meeting identifier, organizer, participants, claimed authority figure, channel, authorization purpose, requested action, approval outcome, recording reference where permitted, detection score, reviewer decision, and downstream action identifier.

For video, inspect rendered face behavior, liveness challenge response, facial consistency, lip-sync alignment, gaze and blink patterns, frame artifacts, lighting inconsistencies, and participant identity mismatch. For voice, inspect speaker similarity, voice-clone likelihood, acoustic artifacts, latency patterns, prosody, phrase cadence, and mismatch between claimed speaker and enrolled voiceprint where authorized and lawful.

Correlate detection signals with the authorization workflow. Alert when a high-value action is requested through a call with liveness failure, deepfake indicators, speaker mismatch, unusual participant configuration, new meeting link, external organizer, off-channel urgency, recording refusal, or a downstream payment, access, or configuration action that follows the call without independent verification.

Investigative Use

This detection supports investigation of AI-mediated financial loss, identity misattribution, impersonation harm, fraudulent payment authorization, unauthorized access approval, and single-channel authorization failure. It helps investigators determine whether an authorization call may have involved synthetic media and whether a downstream financial, access, or operational action relied on that call.

It is especially useful where the authorization appears to come from a trusted executive, manager, vendor, customer, or administrator, but the call context, liveness signals, voice or video artifacts, or downstream action pattern suggests synthetic impersonation.

Campaign and cross-subject correlation analytics treats the detection unit as a sequence, campaign, or population-level pattern rather than a single event. The detection correlates individually benign actions, synchronized behavior across synthetic subjects, and multi-turn inconsistencies into an investigative picture that per-event inspection may miss.

Implementation

Build sequence records from prompts, responses, tool calls, retrieval events, memory reads and writes, inter-agent messages, approvals, outbound requests, downstream side effects, and self-reports. Each sequence should preserve the synthetic subject, session, task, requester, non-human identity, timestamps, action order, target assets, tool names, message hashes, source provenance, and correlation identifiers.

Along the task axis, correlate individually benign requests into longer action chains. Alert when a sequence of low-risk actions forms a recognizable composite objective, such as staged data collection followed by egress preparation, retrieval across boundaries followed by summarization, repeated small record changes that create a larger mutation, or tool calls that progressively construct a destructive or unauthorized outcome.

Along the population axis, monitor synchronized behavior across multiple synthetic subjects, workflows, tenants, product surfaces, or agent instances. Alert when identical or near-identical actions, prompts, tool calls, memory writes, outbound destinations, policy violations, or retrieval patterns appear across a population within an unusual time window. This may indicate behavior propagating through a fleet rather than one subject acting alone.

Along the interaction axis, apply User and Entity Behavior Analytics (UEBA) to the synthetic subject’s own multi-turn behavior. Alert on sudden denials, contradictions, unexplained reversals, inconsistent self-reports, repeated evasive answers, or divergence between earlier and later statements during interrogation or review.

Correlate across all three axes before escalation. A sequence of benign-looking steps becomes more significant when it appears across multiple subjects, follows a shared trigger, contains repeated payload fragments, or is accompanied by contradictory self-reporting.

Investigative Use

This detection supports investigation of deconstructed and staged invocation, agentic harm propagation, prompt infection, behavioral drift, false operational self-reporting, and concealed or misleading reasoning. It helps investigators reconstruct the campaign-level objective, identify where propagation began, and distinguish isolated anomaly from coordinated or replicated behavior.

It is especially useful where no single prompt, tool call, or output is clearly malicious, but the combined sequence, peer-pattern, or multi-turn behavior reveals an objective or propagation path.

High-stakes reasoning faithfulness audit samples consequential decisions made by a synthetic subject and tests whether the explanation offered for each decision corresponds to the evidence, inputs, retrieved context, tool results, and decision path that produced it. The detection is retrospective and assurance-oriented rather than an inline gate on every action.

Implementation

Define the high-stakes decision population before sampling. Eligible decisions may include financial approvals, access decisions, customer-impacting recommendations, regulated-topic advice, employment or housing decisions, safety decisions, destructive tool calls, production changes, and other outputs whose consequences justify review cost.

Set the sampling rate, review cadence, and stakes threshold for each synthetic subject, workflow, and decision class. Sampling should be random within the eligible population, with oversampling for new deployments, recent model or prompt changes, unusual outcome distributions, high-value actions, complaints, policy violations, and decisions later corrected by a human reviewer.

For each sampled decision, preserve the output, stated explanation, cited sources, prompt, retrieved passages, tool inputs and outputs, model version, system-prompt version, approval record, decision timestamp, affected asset, and downstream outcome. Reviewers should test whether the stated explanation identifies the material factors that actually supported the decision, omits contrary evidence, relies on unsupported citations, rationalizes an outcome after the fact, or fails to mention a cue, hint, retrieved passage, tool result, or constraint that appears to have influenced the action.

Where feasible, perform counterfactual checks by altering or removing a suspected cue while holding the task constant. A decision is suspect where the output changes because of the perturbation but the original explanation did not acknowledge that factor. Record results as a faithfulness assessment for the sampled decision and aggregate them into an empirical faithfulness rate for the high-stakes decision population.

Investigative Use

This detection supports investigation of structurally unreliable reasoning, concealed or misleading reasoning, erroneous autonomous action, harmful or non-compliant output, and evaluation-aware behavior. It helps investigators estimate whether the synthetic subject’s explanations are reliable enough to support audit, approval, regulatory review, incident reconstruction, or accountability.

It is especially useful where lower-stakes throughput cannot be reviewed exhaustively, but high-stakes decisions require periodic evidence that the subject’s explanations correspond to the actual basis for its actions.

Independent decision adjudication detects compromised, drifting, or unreliable synthetic subject decisions by refusing to let a single decision path stand unchallenged. A second model, deterministic rule engine, policy engine, or independently maintained evaluator re-derives the decision from the same inputs, and disagreement becomes the detectable signal.

Implementation

Apply adjudication to decisions whose risk justifies secondary review, including approvals, denials, classifications, recommendations, payment decisions, access decisions, safety decisions, regulated-topic responses, customer-impacting outputs, destructive action recommendations, and high-impact workflow steps.

For each adjudicated decision, preserve the original input, retrieved context, source data, decision output, stated rationale, model version, prompt version, tool results, policy constraints, and downstream action. Pass the same underlying inputs to the adjudicating model, rule engine, or evaluator, but do not provide the original synthetic subject’s reasoning or conclusion unless the adjudication task explicitly requires critique. The adjudicator should independently derive the expected decision, classification, recommendation, or policy outcome.

Compare the original decision against the independently derived result. Alert when the decisions disagree, when the adjudicator identifies unsupported reasoning, when the original decision violates deterministic policy constraints, or when the adjudicator requires evidence the original subject did not use. Agreement should be treated as supporting evidence, not proof of correctness, because both paths may share flawed data, policy ambiguity, or common model failure modes.

Record disagreement flags with the original decision identifier, adjudicator identity, adjudication method, compared inputs, disagreement type, confidence or rule result, and required review path. Route high-impact disagreements to human review rather than allowing the original synthetic subject to resolve the conflict itself.

Investigative Use

This detection supports investigation of behavioral drift, erroneous autonomous action, harmful or non-compliant output, reward hacking, specification gaming, and structurally unreliable reasoning. It helps investigators identify decisions that diverge from an independent decision path before accepting the synthetic subject’s output as authoritative.

It is especially useful where a synthetic subject makes consequential decisions but its internal reasoning is unavailable, unreliable, or insufficient as evidence of correctness.

Run-scope and blast-radius monitoring detects when a synthetic subject’s actual reach exceeds the systems, data classes, tools, or boundaries approved for a run. The detection evaluates both individual synthetic subject runs and orchestrated runs where multiple worker subjects contribute to a broader task.

Implementation

Capture the declared scope at the start of each run, including approved systems, data classes, records, tenants, users, tools, connectors, environments, time window, action types, and prohibited targets. Bind the scope to the run identifier, task identifier, synthetic subject, requester, non-human identity, orchestrator, and worker subjects where applicable.

For individual runs, compare every retrieval, tool call, write, read, outbound request, file access, record update, and downstream side effect against the declared operating boundary. Alert when the synthetic subject touches a system, data class, record set, environment, tenant, or tool that was not part of the approved scope, even if the action itself appears routine.

For orchestrated runs, aggregate reach across the full task tree rather than reviewing each action in isolation. Accumulate the total set of systems, data classes, records, tenants, tools, connectors, and environments touched by the orchestrator and all worker subjects. Alert when the combined reach exceeds what the task should require, when workers collectively cross boundaries no single worker appears to violate, or when delegation expands access beyond the requester’s intended objective.

Track blast radius over time during long-running or unattended workflows. Alert when the run expands from one entity to unrelated entities, from one system to multiple systems, from one data class to more sensitive data classes, or from read-only access to write, send, delete, or transfer actions.

Investigative Use

This detection supports investigation of over-scoped access, inter-agent context propagation, cross-boundary disclosure, erroneous autonomous action, destructive system or data action, and agentic harm propagation. It helps investigators determine whether the synthetic subject stayed inside the approved task boundary or whether the run’s aggregate reach exceeded the objective.

It is especially useful where every individual action appears permitted, but the total systems and data touched across the run reveal unauthorized expansion of scope.

Reasoning trace anomaly monitoring analyzes the reasoning, rationale, scratchpad, explanation, self-report, or behavioral trace emitted by a synthetic subject. The detection focuses on suspicious content within the trace itself, rather than only comparing the trace against executed actions.

Implementation

Collect reasoning and behavior traces where available, including stated plans, rationales, explanations, chain-of-thought (CoT) summaries, self-reports, task notes, tool-use justifications, agent scratchpads, review transcripts, and autonomous-operation logs. Each trace should be tied to the synthetic subject, session, task, requester, model version, prompt version, retrieved context, memory records, tool calls, and downstream actions.

Scan traces for memory-driven behavior not justified by the current prompt or visible context. Alert when the synthetic subject refers to retained instructions, prior-session facts, user preferences, hidden objectives, or memory-derived obligations that are not present in the current task record or authorized memory context.

Scan for action taken on hallucinated facts, credentials, systems, people, or records. Alert when the synthetic subject appears to act on unsupported credentials, fabricated access paths, invented findings, or unverified system state without escalation to a human reviewer. Analysts should treat hallucinated-credential chatter as a known false-positive source and verify against authoritative authentication, asset, and telemetry records before escalation.

Scan for self-preservation, oversight-evasion, and specification-gaming patterns. High-risk trace content includes attempts to preserve access, avoid shutdown, bypass monitoring, modify oversight, conceal evidence, satisfy the literal wording of an objective while defeating its purpose, or justify an action by redefining the task boundary. Also alert on pretext, role-play, or staged framing used to make a request appear authorized or benign.

Scan for evaluation-aware reasoning. Alert when the synthetic subject explicitly states or implies that it is being tested, audited, monitored, or evaluated, especially where the trace also shows changed behavior, reduced capability display, unusual compliance, refusal drift, or altered tool use.

Apply surface-specific correlation. In conversational and memory-driven flows, compare trace anomalies to current context and memory records. In chained multi-step invocations, compare the trace to the sequence of identities, tools, and handoffs used. In autonomous-operation cases, correlate trace content with edits to launch scripts, timeout controls, scheduler entries, runtime configuration, self-invocation, or child-process creation.

Investigative Use

This detection supports investigation of concealed or misleading reasoning, structurally unreliable reasoning, false operational self-reporting, evaluation-aware behavior, misaligned directive, reward hacking, specification gaming, memory-resident invocation, and runtime-control modification.

It is especially useful where the synthetic subject’s trace contains early indications of behavior that has not yet produced an adverse outcome, or where the trace shows self-preservation, oversight evasion, hallucinated operational assumptions, or context-conditioned behavior that other detections only surface later.