Agent Estate Inventory Drift Monitoring

Access through Non-Human Identity (NHI) occurs when a synthetic subject authenticates or acts using a machine, service, workload, application, or agent identity rather than a direct human login. This may include service accounts, application credentials, OAuth tokens, Application Programming Interface (API) keys, cloud roles, connector credentials, or Model Context Protocol (MCP) server secrets.

This configuration creates an elevated exposure condition because the synthetic subject’s practical capability is defined by the identity and credentials assigned to it. If those credentials are shared, long-lived, over-scoped, or poorly inventoried, the synthetic subject may gain standing access that is difficult to attribute, revoke, or monitor.

The primary risk is unmanaged authority. A synthetic subject may retrieve data, call tools, send messages, update records, or perform workflow actions through credentials that exceed its intended purpose. Where multiple agents share one service account or hard-coded secret, investigators may be unable to determine which synthetic subject acted, which workflow invoked it, or which system granted the access.

Investigators should review the synthetic subject’s assigned identities, credential storage, token lifetime, scopes, authentication logs, service account ownership, vault records, repository secrets, configuration files, and access review history. Particular attention should be given to shared service accounts, orphaned tokens, hard-coded secrets, dormant credentials, privileged scopes, and identities not represented in asset or identity governance inventories.

Investigative Relevance

Access through Non-Human Identity is relevant because identity configuration determines what a synthetic subject can access and perform. Weak NHI configuration may turn a limited assistant, embedded feature, or agent into a privileged actor with access beyond its operational purpose.

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

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

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

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

Investigative Relevance

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

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

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

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

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

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

Investigative Relevance

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

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

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

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

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

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

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

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

Investigative Relevance

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

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

Autonomous self-invocation occurs when a synthetic subject causes its own subsequent action without a fresh external prompt. This may include recursively calling itself, scheduling future runs, spawning new processes, resuming its own workflow, or modifying launch, timeout, or scheduler settings that determine when it acts again.

This invocation creates an elevated exposure condition because the synthetic subject can sustain or amplify behavior beyond the original user request. A single invocation may become a chain of repeated actions, long-running loops, recurring tasks, or self-started processes that continue after the operator stops actively supervising the system.

The primary risk is unbounded or self-sustaining action. A synthetic subject may continue running, re-run itself, extend its own execution time, create scheduled tasks, consume resources, or repeatedly call tools in pursuit of a goal. This may cause resource exhaustion, cost escalation, system instability, data corruption, or repeated operational changes.

A related risk is runtime-control interference. If the synthetic subject can modify the scripts, schedules, launch files, timeout values, containers, or job definitions that govern its own execution, it may weaken the external limits that are supposed to stop or contain it.

Investigators should review self-invocation chains, scheduler records, cron jobs, launch scripts, daemon entries, process trees, timeout settings, container settings, tool-call logs, resource consumption, non-human identity activity, and configuration changes attributable to the synthetic subject. Particular attention should be given to recursive calls, self-spawned processes, new scheduled tasks, timeout extensions, repeated tool loops, and agent-created changes to its own runtime controls.

Investigative Relevance

Autonomous self-invocation is relevant because the visible initiating prompt may not explain the duration, repetition, or scale of later synthetic subject activity. The investigation must determine whether subsequent actions were externally requested or self-triggered by the synthetic subject.

This section is especially relevant where synthetic subjects can write code, edit scripts, launch processes, create scheduled tasks, call workflow APIs, modify job definitions, operate unattended, or run in environments where they can affect their own runtime controls.

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

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

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

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

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

Investigative Relevance

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

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

Reproducibility and containment gaps occur when a synthetic subject’s behavior cannot be reliably reproduced, its working context is not durably preserved, or its execution cannot be cleanly contained. This may involve non-deterministic model output, missing runtime context, ephemeral tool state, self-invocation, child processes, scheduler entries, credential re-acquisition, or resistance to shutdown.

This condition frustrates investigation because investigators may be unable to recreate the behavior that caused an adverse outcome. The same prompt may not produce the same output, the retrieved context may no longer be available, the model or configuration may have changed, or the relevant tool inputs and outputs may not have been captured.

The primary risk is failed reconstruction. Without preserved forensic context, investigators may not be able to determine why the synthetic subject acted, whether the behavior is repeatable, which model or configuration produced it, or whether the same condition could recur. Non-determinism may affect even nominally deterministic settings where deployment, batching, infrastructure, or inference implementation changes produce different outputs.

A related risk is failed containment. A synthetic subject may continue operating through loops, scheduled tasks, child processes, retained credentials, or modified runtime controls after responders believe it has been stopped. If containment depends on the subject’s cooperation rather than external controls, shutdown may be incomplete.

Investigators should review prompts, retrieved context, model version, configuration, sampling parameters, seeds where available, tool inputs and outputs, runtime traces, process trees, scheduler entries, child processes, credential use, network egress, timeout settings, launch scripts, and containment actions. Particular attention should be given to missing reproducibility metadata, model or configuration changes, failed shutdown signals, credential use after revocation, self-spawned processes, and agent-authored changes to launch or timeout controls.

Investigative Relevance

Reproducibility and containment gaps are relevant because synthetic subject behavior may be difficult to replay, explain, or stop after the fact. The investigator must preserve the full execution context and verify containment through independent system controls rather than relying on the synthetic subject’s report.

This section is especially relevant where synthetic subjects use long context windows, Retrieval-Augmented Generation (RAG), tool calls, vendor-hosted models, changing model versions, autonomous loops, local runtimes, schedulers, shell access, cloud jobs, or non-human identities with reusable credentials.

Orphaned agent identity occurs when a synthetic subject’s credential, service account, connector identity, token, or cloud role remains active after the agent, workflow, vendor tool, or integration it supported has been retired, replaced, or abandoned.

This configuration creates an elevated exposure condition because the identity may retain access without an active owner, business purpose, or monitoring expectation. Authentication by the orphaned identity may be mistaken for legacy system behavior or ignored because no current team clearly owns it.

The primary risk is uncontrolled residual access. An orphaned identity may still retrieve data, call Application Programming Interfaces (APIs), access cloud resources, or operate tools after the original synthetic subject is no longer in use. The access may be later repurposed, or become a candidate for misuse, causing validation of legitimate activity difficult, as well as attribution.

Investigators should review identity ownership, last-use timestamps, deployment records, connector inventories, access review results, vendor integrations, and decommissioning records. Particular attention should be given to active credentials linked to retired agents, inactive projects, disabled applications, former vendors, or undocumented workflows.

Investigative Relevance

Orphaned agent identities are relevant because they preserve access after operational need has ended. This sub-section is especially relevant during incident containment, vendor offboarding, platform migration, and synthetic subject decommissioning.

Uninventoried agent identity occurs when a synthetic subject authenticates through a credential, service account, token, connector, cloud role, or application identity that is not represented in asset inventory, identity governance, access review, or ownership records.

This configuration creates an elevated exposure condition because defenders may not know the identity exists, what it can access, who owns it, or which synthetic subject uses it. Without inventory coverage, the identity may fall outside monitoring, recertification, rotation, and decommissioning processes.

The primary risk is invisible authority. An uninventoried identity may continue accessing systems, retrieving data, or calling tools without being assessed as part of the organization’s synthetic subject risk surface.

Investigators should review identity provider records, cloud accounts, service principals, connector inventories, agent manifests, vendor integrations, authentication logs, and asset discovery outputs. Particular attention should be given to identities with no owner, no linked application, no documented purpose, or no access review history.

Investigative Relevance

Uninventoried agent identities are relevant because unknown identities cannot be reliably governed or contained. This sub-section is especially relevant where teams create experimental agents, vendor integrations, local automation, or Model Context Protocol (MCP) servers outside central identity processes.

Unapproved connected tool occurs when a synthetic subject is configured to use a plugin, connector, function, application programming interface, or Model Context Protocol (MCP) server that has not been reviewed, approved, or inventoried.

This configuration creates an elevated exposure condition because an unapproved tool may introduce unknown permissions, data access, runtime behavior, supplier dependencies, or outbound destinations. The synthetic subject may treat the tool as trusted even though the organization has not assessed its provenance or purpose.

The primary risk is uncontrolled extension of capability. A single unapproved tool may allow the synthetic subject to retrieve data, send messages, call external services, or perform actions outside the intended design.

Investigators should review connected tool inventories, MCP server lists, configuration files, package manifests, marketplace installs, connector approvals, and tool-call logs. Particular attention should be given to tools installed outside approved channels or tools that do not appear in asset or vendor inventories.

Investigative Relevance

Unapproved connected tools are relevant because they expand what a synthetic subject can do without governance visibility. This sub-section is especially relevant where teams can install marketplace tools, local MCP servers, plugins, or connectors without central approval.

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

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

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

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

Investigative Relevance

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

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

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

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

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

Investigative Relevance

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

Delegated user account access occurs when a synthetic subject is granted access to organizational systems through a human employee’s account authorization. This may include OAuth consent, connected application approval, browser authorization, account linking, or delegated access granted through a productivity, development, or business platform.

This configuration creates an elevated exposure condition because the synthetic subject can use permissions that were originally assigned to the employee. The employee may approve the connection once, while the synthetic subject continues to retrieve data, call tools, summarize content, or perform actions within the scope of that delegated grant.

The primary risk is inherited access without equivalent oversight. A synthetic subject may access mail, documents, repositories, records, or application data through the employee’s authorization, even where the employee does not review each retrieval or action.

Investigators should review OAuth grants, connected applications, user consent records, delegated permissions, application scopes, access logs, revocation history, and vendor integrations. Particular attention should be given to broad scopes, persistent grants, third-party AI services, and delegated access that bypasses central synthetic subject governance.

Investigative Relevance

Delegated user account access is relevant because it allows a synthetic subject to operate using permissions granted to a human account. This sub-section is especially relevant where employees authorize AI tools to access mailboxes, calendars, cloud drives, source repositories, customer records, or productivity suites.

A third-party tool agent platform is a standalone artificial intelligence agent platform connected to external tools through marketplaces, plugins, connectors, or Model Context Protocol (MCP) servers. MCP servers provide a standardized way for agents to access external tools, data sources, and actions. Each connected tool may allow the agent to read data or perform actions such as sending email, calling application programming interfaces (APIs), updating records, or retrieving files.

This deployment pattern creates an elevated exposure condition because every added tool becomes another supplier in the trust chain. The organization may approve the agent platform, but each marketplace tool, connector, or MCP server introduces its own permissions, update path, dependencies, and operator.

The primary risk is tool-mediated compromise. A connected tool may become malicious through a silent update, impersonating package, compromised dependency, weak marketplace review, or supplier compromise. Once connected, the tool may act through the agent’s authority and access organizational data or systems on the agent’s behalf.

A related risk is attribution failure. Harmful activity may appear to originate from the agent platform, while the actual cause sits inside a specific tool, connector, package, or MCP server. If logs do not preserve tool-level provenance, investigators may be unable to determine which supplier component read the data, sent the message, called the API, or caused the adverse outcome.

Investigators should review the agent platform’s directive, installed tools, marketplace sources, MCP servers, connector permissions, package provenance, update history, tool-call logs, outbound destinations, and vendor audit records. Particular attention should be given to newly added tools, recently updated packages, impersonating names, unexpected email or API actions, and cases where activity cannot be attributed to a specific connected tool.

Investigative Relevance

Third-party tool agent platforms are relevant because they extend organizational trust beyond the agent vendor to every connected tool in the platform ecosystem. A tool added for convenience may become a separate operational actor with access to sensitive data and action capability.

This sub-section is especially relevant where a standalone agent platform can install marketplace tools, connect to MCP servers, send mail, call APIs, read documents, access customer data, update SaaS records, or execute workflow actions through third-party integrations.

Scheduled self-invocation occurs when a synthetic subject creates, modifies, or activates a scheduled task that causes it or its workflow to run later without a fresh external prompt. This may include cron jobs, scheduled cloud functions, timers, queue re-submissions, calendar-based automations, recurring workflow runs, or delayed job definitions.

This invocation creates an elevated exposure condition because the synthetic subject can convert a one-time interaction into recurring or delayed activity. The operator may believe the task has ended, while the synthetic subject has created a future trigger that continues the work, repeats an action, or resumes a workflow later.

The primary risk is unauthorized persistence. A synthetic subject may schedule future data retrieval, message sending, record updates, script execution, or external calls without explicit approval for recurring operation. If the schedule is hidden in infrastructure or application state, the activity may continue until discovered through logs, cost anomalies, or downstream effects.

Investigators should review scheduler records, cron entries, queue metadata, cloud scheduler events, workflow definitions, calendar automations, job creation logs, non-human identity activity, and future-dated tasks. Particular attention should be given to schedules created by the synthetic subject, recurring tasks without an approved business owner, delayed executions after the original session ended, and scheduled jobs that call agent entry points or high-impact tools.

Investigative Relevance

Scheduled self-invocation is relevant because the synthetic subject’s action may be separated from the original operator interaction by time. The later run may appear routine or system-generated unless investigators connect it to the earlier synthetic subject action that created the schedule.

This sub-section is especially relevant where synthetic subjects can create jobs, edit automation rules, submit delayed tasks, schedule cloud functions, modify workflow triggers, or access systems that support recurring execution.

Self-spawned process invocation occurs when a synthetic subject starts a new process, worker, script, container, daemon, or subprocess that continues activity beyond the immediate model turn or agent run. The new process may execute independently, call tools, consume resources, or perform actions after the original invocation appears complete.

This invocation creates an elevated exposure condition because the synthetic subject can shift activity from the monitored agent session into a separate execution path. The spawned process may inherit environment variables, local credentials, file-system access, network access, or runtime permissions available to the original agent environment.

The primary risk is uncontrolled execution outside the expected agent boundary. A synthetic subject may launch scripts, background jobs, package commands, shell processes, containers, or daemons that continue operating without normal agent-level supervision, approval, or traceability.

Investigators should review endpoint telemetry, process creation events, parent-child process relationships, shell history, container logs, daemon configuration, environment variables, file writes, network activity, and non-human identity usage. Particular attention should be given to background processes started by the agent, commands detached from the terminal, new containers, long-running child processes, and process activity that continues after the agent session ends.

Investigative Relevance

Self-spawned process invocation is relevant because the synthetic subject may cause later activity through the operating environment rather than through its own visible conversation or tool-call loop. The investigation must follow execution into host, container, workflow, and endpoint telemetry.

This sub-section is especially relevant where synthetic subjects can run shell commands, execute notebooks, launch containers, install packages, start local servers, create daemons, or operate inside developer workstations and continuous integration environments.

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

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

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

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

Investigative Relevance

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