Above Theory and Forscie unveil the Synthetic Insider Threat Matrix™
Read more
Aviv Nahum
September 19, 2026
Aviv Nahum
Sep 22, 2026
A map of enterprise AI: what it is, where it acts, and what it takes to understand the risk.
I think there is too much fear, uncertainty and doubt around AI agents. Too much of the conversation makes it sound as though we need to discard everything we know about security and start again. I see a familiar core problem: an actor has access to information and the authority to do something with it. We need to understand that access, bound its use, and establish what happened when the outcome is wrong.
AI increases the volume and speed of work, the number of actions that can be delegated, and the distance between a person's request and its eventual effect. Those changes matter. They can amplify weak permissions and make manual review harder to sustain. Prompt injection, unreliable planning and persistent state also deserve specific controls; calling the foundations familiar is not a claim that every mechanism is unchanged.
My starting position is that mastering the basics puts us in a much stronger position: know the actors, scope their permissions, protect the data, verify consequential actions, and be able to stop the work. The same threat-model questions still apply. The task is to carry them into every place an agent can act, at the scale and speed at which it operates.
An employee asks an assistant to prepare a customer renewal. The request sounds simple. Completing it could involve searching internal documents, reading a customer record, opening a spreadsheet, calculating a price, and drafting an email. With different permissions, the same assistant could also update the record and send the offer.
The security boundary changes with those capabilities. The chat window does not tell us which boundary we have crossed.
Enterprise AI is becoming part of how work moves between people, applications, and systems. Some deployments answer questions. Others retrieve company knowledge, operate a computer, write software, or carry out business processes. A single task can involve several of these arrangements, using several identities along the way.
We need a map that survives changes in product names. That map begins with the work: what the system can read, decide, and change; where those actions happen; and whose authority makes them possible. It ends with evidence of what actually occurred.
This article follows that map from the agent itself to the places an enterprise can collect telemetry. The connection that emerges is familiar: trusted access can produce harmful outcomes, whether a person acts directly or delegates the work to software.
A model generates output. An agent is a system that uses model output to choose and carry out actions toward a goal. The software around the model gathers context, makes capabilities available, executes selected operations, and decides when to continue or stop.
That surrounding software is often called the harness or orchestrator. A tool is a capability it can invoke: search a repository, read a document, run a command, send an email. The executor is the process or service that performs the operation. These roles can live together or be distributed across systems.
There is a useful distinction between a workflow whose steps are prescribed in code and an agent that chooses its next step. Many enterprise systems combine both: a controlled workflow delegates a bounded task to an agent, then resumes a conventional approval process. Anthropic describes this distinction in its engineering guidance on workflows and agents.
An agent does not need permanent memory, unrestricted access, or the ability to work indefinitely. A short research task can be agentic. A scheduled process can remain tightly constrained. “Agent” describes how work is directed; it does not tell us how powerful, persistent, or risky a particular deployment is.
The security significance lies in the capabilities attached to that loop. Generating a suggested refund and issuing a refund are different operations. The model might be identical in both cases; the access and execution paths are not.
A useful enterprise landscape starts with a few recurring patterns. They overlap because a system can perform several kinds of work.
Conversational assistance turns submitted information into an answer, summary, or draft. Its exposure includes what people submit and how they use the output. A chat feature alone does not establish that the system can act elsewhere.
Knowledge assistance retrieves information from enterprise sources and uses it to answer a question. Search, source permissions, indexing, and the selection of context become important. Glean is one example: its Assistant uses company knowledge and respects access permissions. That makes retrieval a distinct security boundary even before an action is taken. Glean Assistant documentation.
Workspace and coding agents operate on working materials: files, repositories, terminals, tests, and development tools. A coding agent is a specialization of the agent loop for software work. Claude Code and Codex illustrate this pattern; the relevant questions concern the workspace, commands, credentials, and external services available to the particular session.
Application and business-process agents work through business capabilities: reading a ticket, changing a customer record, preparing an invoice, or submitting an approval. They may be embedded in a SaaS product or assembled from several applications. The most consequential event may be a valid API transaction inside a system the employee never opens.
Browser and computer-use agents operate interfaces. Here, a browser can be both an entry point for a person and a tool operated by the agent. An authenticated session may supply access without a new sign-in for every action.
Background and delegated work describe how tasks are initiated and composed. A schedule can start a task; one agent can assign work to another. Neither tells us where execution occurs or whether the work uses a person's delegation, a service account, or a dedicated agent identity.
Product boundaries can cross these patterns. A knowledge platform can provide its own assistant and also supply retrieval tools to another agent. For example, Glean exposes capabilities through MCP that external clients can use. In that arrangement, Glean is part of another system's action path. Glean MCP documentation.
This is why an inventory field labeled “AI tool” is insufficient. A useful record describes the deployment: its purpose, owner, enabled capabilities, execution environments, authorization, and retained state.
There is something odd about the way we talk about “defending against AI.” Claude is an application. ChatGPT is an application. More precisely, each name now covers several clients and services. They have accounts, network connections, permissions, integrations and release versions. We sometimes talk about them as if they were an abstract force instead of software we can inspect and govern.
An application name can be a useful policy selector. It is a poor substitute for a threat model. The same application can support an approved workflow in a managed account or move sensitive information through a personal account. Blocking it may be a reasonable decision, but the security objective is to protect the information and business action involved. The exposure does not disappear if the same work moves to another application.
This is familiar application security with additional behavior to understand. A model can interpret untrusted content as instructions, select tools and delegate work. Those capabilities change the controls we need. They do not remove the need to know which software is running, whose account it uses, what it can reach and what it actually does.
That distinction keeps the discussion practical: the policy can survive a change of product, while the collection method must fit the specific implementation. Certificate handling, audit exports and runtime hooks are application details. They determine whether the evidence we need is available at all.
To locate a deployment, separate six components: the interface or trigger, model inference, orchestration, execution, resources, and state.
A person might initiate a task from a laptop while a provider operates the model and agent loop. A remote executor might run code, while a connector accesses a SaaS application and an approved bridge reads a local file. The resulting documents and credentials can outlive the original interaction.
Local, cloud, and managed deployments therefore require more precise language.
In a local deployment, orchestration or execution runs on infrastructure the enterprise or employee controls. Model inference can still be remote. In a cloud task, a remote environment performs the work. A managed agent service takes responsibility for parts of the agent infrastructure, but the executor and connected resources may be supplied separately. “Managed” is a responsibility boundary, not a guarantee that every component sits with one provider.
Concrete examples make the distinction easier to see. Claude Code Remote Control can expose a host-based session through another interface; interacting remotely does not relocate execution. Codex cloud runs tasks in remote environments. These are different placements of work behind familiar interfaces. Claude Code Remote Control, Codex cloud.
Managed services add another combination. OpenAI's Agents API architecture separates its hosted harness from execution environments and externally implemented tools. Claude Managed Agents similarly describes agents, environments, sessions, and events as distinct objects. The architectural lesson is to identify which party operates each component. OpenAI Agents API architecture, Claude Managed Agents.
This distinction also explains coverage limits. A laptop sensor can be valuable where processes and files are local. Its presence alone cannot establish what happened in a provider's workspace. Conversely, a hosted conversation record may contain tool requests while lacking the authoritative record of a change in the destination application.
Consider a hypothetical assistant preparing that renewal brief. A browser starts the task. A hosted orchestrator consults a model, retrieves CRM information through a connector, and uses a remote executor to calculate pricing. A state store retains the draft and task history. An email tool can then create a draft or send a message, depending on its permissions.
Each component supplies a different part of the account. The model provider may record an inference request. The executor may record a calculation. The CRM and email service record their own operations. None of those sources alone necessarily knows the entire task.
Follow the identities separately. The business owner is accountable for the deployment. The initiator starts the work. The agent or application principal represents software seeking access. A downstream principal is the identity a particular resource actually authorizes. One person can occupy several roles, but the roles should not disappear into one username.
An agent might use delegated access to read a salesperson's customer records, then use a separate service identity for another operation. An authenticated browser session can supply yet another access path. At each boundary, establish what authority was granted, to which actor, for which resource and operations. Do not assume the initiating user's name will survive into every downstream log.
Microsoft Entra Agent ID provides a concrete example of identity infrastructure that distinguishes agent identities and supports both directly granted and delegated access. The general lesson extends beyond that implementation: an agent's identity and its execution location are separate properties. Microsoft Entra agent identities.
The consequence is practical. Permission to read a customer record need not imply permission to export the customer database. Permission to prepare a draft need not imply permission to send it. Those distinctions belong at the capabilities and resources that enforce them, and in the evidence that explains their use.
“We have AI visibility” is an incomplete statement. Visibility into usage is different from visibility into actions, and both differ from understanding why an action matters.
Discovery establishes which applications, integrations, models, identities, or deployments have been observed. A domain visit is evidence of contact with a service; it is not a complete inventory of agents.
Content visibility concerns the request, response, attachments, and retrieved information available at a particular point. A captured user prompt may omit context later added by a connector or orchestrator.
Execution visibility concerns tool requests, approvals, results, commands, and other operations. A model proposing a tool call does not prove that the tool ran successfully.
Authority visibility identifies the principals, permissions, grants, and authenticated sessions used along the path. The person who started a task and the principal that changed a record may be different.
Outcome visibility establishes what was read, sent, created, modified, or deleted in the destination system. It is the difference between a report of completion and a recorded effect.
Business context connects those observations to purpose: whose account this was, whether the recipient belonged in the workflow, what the employee or agent was assigned to do, and which policy applied. That understanding is assembled from evidence and organizational context; it does not emerge automatically from a larger log feed.
A useful coverage statement therefore names the population, environment, event types, collection delay, content limits, and missing paths. “Tool events from these managed deployments, excluding direct shell activity” is more useful than an unqualified claim of full visibility.
Telemetry can be collected wherever a meaningful interaction leaves a record. Some collection points are specific to AI. Others already exist in identity, endpoint, cloud, and application infrastructure.
The comparison below is an architectural synthesis, organized by where evidence originates. It describes what a properly configured implementation can provide, not a promise that every product exports every field. Collection and enforcement are separate: a logging interface may observe an action without having any opportunity to stop it.
There are important differences even within model-side collection. An AI gateway is generally a routing point for model traffic. An inference hook is an interception mechanism inside a supported provider flow. Neither name guarantees the same payload or enforcement scope.
For example, Claude's documented Enterprise Inference Hooks gate covered model requests on the provider side. Their scope is not universal Platform API coverage, and denying inference does not establish that submitted information never reached the provider. Claude Inference Hooks.
Provider logging is another mechanism. Amazon Bedrock documents optional invocation logging for supported calls, with endpoint-specific coverage and configurable content types. That illustrates why “we use this provider” and “we collect this evidence” are separate statements. Bedrock invocation logging.
Consider an employee submitting the same text through a browser and a native macOS app. A managed browser integration may observe the supported page interaction. That does not give it access to the native application's prompt. An endpoint sensor might identify the process and connection without exposing the conversation body. This is a coverage question about two clients, even when both display the same product name.
TLS inspection—often still called SSL inspection—tries to expose encrypted traffic at an authorized intermediary. An endpoint component may steer traffic to a remote inspection service, or inspection may occur locally. Neither arrangement proves that the application accepts the inspection certificate, that the relevant traffic follows that route, or that the collector understands its payload.
Certificate pinning illustrates the difficulty: an application can require an expected certificate or key and reject the intermediary's replacement. A separate application trust store can also reject a corporate certificate. Similar errors can therefore have different causes. Cloudflare documents these trust-store and pinning issues for desktop applications, including ChatGPT. Cloudflare Gateway troubleshooting.
ChatGPT on macOS is a concrete example of the operational limit. OpenAI documents that TLS inspection can cause certificate errors and disrupt the native app, and directs organizations with mandatory inspection to Support. That supports a scoped statement about compatibility; it does not establish that every version, account or inspection product behaves identically. A decryption exception may restore connectivity while leaving prompt content invisible on that inspection path. OpenAI network guidance.
Claude Code offers a different documented arrangement: corporate proxies and custom certificate authorities are supported, with trust-store behavior dependent on the runtime and configuration. That is more precise than declaring “Claude is not pinned.” Claude Code, ordinary Claude chat and different desktop modes should not inherit one another's coverage claims. Claude Code enterprise network configuration.
“Claude has hooks” needs the same precision. Claude Code lifecycle hooks run at specified runtime events; PreToolUse can govern a supported tool invocation. That is different from observing ordinary chat, and it does not intercept every way information can enter context. Claude Code hooks.
Claude Enterprise inference hooks operate on the provider side for governed requests across supported chat and agent surfaces. They can inspect the documented transcript payload and return an allow/deny decision before inference. They are a separate mechanism from Code hooks: data has already left the client, and a model-request gate is not a universal pre-tool gate. Claude inference hooks.
Compliance APIs provide another route. Claude exposes supported organizational activity and content records; OpenAI provides covered workspace compliance records for eligible organizations. These are useful sources for investigation without assuming successful TLS interception. They are not equivalent to an inline hook, and an organization's access should not be assumed to cover employees' separate personal accounts. Claude Compliance API, OpenAI compliance guidance.
The useful comparison is therefore not “hooks versus no hooks.” It is which client, account and event a mechanism covers, what it exposes, and when it can act. Test a synthetic prompt, attachment and consequential action through the actual deployment, then check the records. Decrypted bytes, a captured prompt and a verified business outcome remain different achievements.
Runtime instrumentation can provide a richer account than network activity because it understands application events. Its depth still depends on configuration. Codex documents optional OpenTelemetry export, including control over prompt logging. Claude Code provides lifecycle hooks and separate telemetry configuration. These are examples of collecting evidence where the agent loop operates. Codex advanced configuration, Claude Code hooks, Claude Code monitoring.
The same principle applies to enterprise platforms. Glean documents background-agent run history, traces, and audit events. An operator should distinguish what is visible in the product from what can be exported and correlated elsewhere. Glean background-agent security.
Tool gateways deserve their own treatment. MCP standardizes interactions between clients and servers exposing capabilities; it does not make every operation in an agent's environment an MCP operation. The security design must follow the authorization and downstream resource boundary, including the protocol's guidance against inappropriate token passthrough. MCP security guidance.
These sources remain relevant when the actor is an agent. Entra sign-in logs distinguish several principal and sign-in types. CloudTrail distinguishes management and data events. Kubernetes audit policy controls the detail recorded for API requests. Each describes a specific boundary rather than the entire task. Entra sign-in logs, CloudTrail event types, Kubernetes auditing.
Application and development records add other perspectives. Microsoft Purview provides audit capabilities across supported services; GitHub's enterprise audit log records covered enterprise activity. Neither should be mistaken for a complete transcript of every agent operation. Purview auditing, GitHub enterprise audit log.
The value of this atlas is the ability to select complementary sources. A model record can explain the request, a runtime event can identify the attempted operation, and a destination record can confirm the result. Buying or enabling one category does not eliminate the need to understand the others.
For a local coding task, runtime events and endpoint evidence can explain workspace activity; repository history and CI results establish what was submitted and executed later. A model gateway adds visibility into the inference route it actually governs.
For a hosted business agent, session records and connector instrumentation may explain the decisions and attempted operations, while identity logs and destination transactions establish access and effects. An employee's device may contain very little of that execution evidence.
For a knowledge assistant, the useful combination may be the question, retrieved source references, permission decisions and the answer. If that assistant is later given write or send capabilities, the evidence plan needs to expand with its authority.
These are starting combinations, not universal collection recipes. The test is whether the selected sources can answer the important questions about an actual deployment.
Return to the hypothetical renewal task. A prompt asks for a draft. Retrieval supplies the customer history and a pricing worksheet. A tool requests an email send. The mail system records a message to an external recipient.
Those observations raise different questions. Did the original task permit sending? Was there a specific approval? Did a retrieved document introduce an instruction? Was the recipient expected? Which identity authorized the send, and which information was actually attached?
The prompt alone cannot settle them. Neither can a sign-in event or a successful tool response. A defensible account connects the task, relevant inputs, authority, execution, and resulting object, preserving uncertainty where the records cannot be joined.
Timing matters too. A pre-action decision can prevent a covered operation. A later event can support detection and response. An audit export can support reconstruction. All are useful, but they make different promises. Similarly, observing a tool request and proving that a message was sent are different achievements.
More content is not always better evidence. Prompts and retrieved documents can contain sensitive information. Collect the fields needed for the purpose, protect access to content, apply retention, and keep the record of important effects outside the agent's own ability to alter it. Hidden model reasoning is not a substitute for externally observable actions.
The practical test is one meaningful task. Establish that ordinary work succeeds, attempt an authorized synthetic out-of-scope action, and verify where it is denied or observed. Then stop the task and check its remaining access, schedules, and child work. That exercise reveals more about coverage than a list of connected integrations.
There is a reason this map keeps returning to identities, permissions, business purpose, and consequences. They connect AI security to a problem enterprises already have: trusted access being used in ways that create risk.
An employee can export sensitive records directly. An agent can export them on the employee's behalf. An attacker can influence an agent that already has permission to read them. The initiating cause differs, but the path into the enterprise's information and business processes can run through the same trusted access.
That is the insider-risk connection. The subject is no longer only the person at the keyboard. It also includes the software acting with delegated or independently granted authority, and the relationship between them.
Identity provides the foundation for attribution and access control, but it does not establish purpose. A valid token can authorize an inappropriate transaction. A separate agent identity can improve accountability without explaining why the action occurred. NIST's discussion of agent identity highlights familiar problems with shared credentials, long-lived access, and overly broad permissions—problems whose consequences can grow with automated execution. NIST on agent identity and authorization.
This does not make every AI risk an insider incident. Model supply chains, training systems, and infrastructure have their own security concerns. Nor does it give an agent human motives. Prompt injection, unreliable planning, delegated work, and persistent state introduce mechanisms that need specific controls. OWASP's agent-security guidance covers these distinctions alongside tools, permissions, and operational oversight. OWASP AI Agent Security.
The useful convergence is at the level of enterprise outcomes: disclosure, unauthorized changes, abuse of access, fraud, or disruption. Understanding those outcomes requires following the work across human and synthetic actors, rather than ending the investigation at an application label.
The Synthetic Insider Threat Matrix offers a complementary investigative vocabulary: Directive, Configuration, Invocation, Adverse Outcome, and Opacity. Those categories separate intended work, enabling conditions, triggers, harm, and uncertainty. They are analytical lenses, not a mandatory sequence or proof of malicious behavior. Synthetic Insider Threat Matrix.
An enterprise can start with a simple change in its questions. Alongside “Which AI products do we use?”, ask: What work have we delegated, under whose authority, and how would we know if it went wrong?
That question remains useful whether the next deployment is a knowledge assistant, a coding agent, an embedded SaaS feature, or a managed cloud service. The interfaces will keep changing. The need to understand trusted access—and what it does to the business—will remain.
The application-boundary, TLS-inspection, hooks and compliance discussion was checked against provider documentation on September 19, 2026; other product examples retain their September 15, 2026 research date. The renewal scenario is hypothetical. The map and collection comparison are the author's synthesis; documented capabilities were not independently tested in live deployments.
