AI Investigating AI: The Architecture Behind Securing Synthetic Insiders

Satya Nadella recently published an essay, Models as Insider Risks in the Super Intelligence Era, that raises an important architectural question for anyone building AI systems.

His argument is that we need to treat increasingly capable AI models as insider risks, applying the same principles of independent observation, access control, auditing, and containment that we've developed for privileged human actors.

One sentence stood out to me: “We need to separate the supply of intelligence from the authority over it.”

As the CPTO of Above Security, I spend much of my time working on a closely related problem: how do we build AI systems that can continuously investigate other AI systems operating inside an enterprise?

There's an apparent paradox here. If models are inherently difficult to explain, susceptible to manipulation, and capable of making mistakes, why would we use another model to determine whether their behavior is safe?

The answer has shaped many of our architectural decisions at Above. We can use AI to reason about behavior without allowing it to become the sole authority over the underlying evidence. Getting there requires a much more sophisticated system than connecting enterprise logs to a language model.

Here's how we've approached it.

1. First, we need to observe the AI agent independently

Consider an employee using Claude Code to work on a project. The agent reads source code, executes commands, interacts with GitHub, and accesses internal documentation. It may also connect to cloud services, retrieve customer information, or write files through integrations. Some of these actions happen locally. Others may execute remotely.

Now imagine that the agent starts collecting information unrelated to its original task and transfers it to an external destination.

If our only visibility comes from the agent's own conversation or execution summary, we're asking the system being investigated to provide the evidence against itself.

Satya's principle of independent observability becomes particularly important here.

At Above, we approach the problem by connecting activity from multiple independent sources.

We ingest what I like to call the telemetry soup: endpoint activity from CrowdStrike Falcon and Microsoft Defender; browser activity; identity information from Okta and Microsoft Entra; communications from Outlook, Google Workspace, Slack, and Teams; activity from enterprise applications; and available records from AI platforms such as Claude, ChatGPT, and Copilot.

Each source sees a different part of the environment. An AI platform may show the prompt and response. An endpoint sensor may reveal the process and file operations. Salesforce may record which customer records were retrieved. An identity provider can help establish which credentials and permissions were involved.

When correlated, these observations give us a more complete account of what the agent actually did. Crucially, that account doesn't depend entirely on the agent explaining itself.

Going deeper without deploying another endpoint agent

One of our architectural decisions was to leverage existing endpoint security infrastructure rather than require a new dedicated endpoint agent for our investigative platform.

For example, when an investigation needs additional endpoint evidence, we can use capabilities such as CrowdStrike Falcon's Real Time Response to retrieve relevant information.

This allows us to combine existing endpoint telemetry with targeted investigative collection. We're interested in answering the next investigative question, rather than collecting every possible detail from every machine continuously.

The distinction matters for performance, cost, and operational complexity.

2. Observing an action is only the beginning

Let's say an AI agent accesses a customer account plan in Salesforce. We now have evidence that the action occurred. We may also know which identity was used, which permissions were available, and which application initiated the request.

But should the agent have accessed that information? Answering that question requires understanding the organization.

A sales agent supporting an active renewal might reasonably access the account plan. A coding agent working on an unrelated repository probably shouldn't need the same information.

And even a legitimate sales agent could create risk if it aggregated confidential information across unrelated customers and sent it to an external service.

This is where we've invested heavily in business context. Our behavioral model connects people, AI agents, business data, applications, and devices.

We also use process-mining techniques to understand how work actually happens across the enterprise.

A customer renewal, for example, may involve Salesforce records, shared documents, email conversations, internal approvals, and several human or synthetic participants. The process exists across those systems, but no individual system has the complete picture.

By reconstructing the relationships and sequences involved, our investigators can evaluate an agent's activity in the context of the business process it was supposed to support.

This is particularly important for agentic AI. An agent can execute hundreds of technically authorized actions while pursuing a task. Evaluating each action independently may reveal very little about whether the overall behavior was appropriate.

We need to understand the purpose of the activity, how it evolved, and where it diverged from the expected business process.

3. We built AI investigators around evidence, not unlimited access to logs

Here's a tempting implementation: take all the enterprise telemetry, put it into a large context window, and ask an LLM, “Is this AI agent doing anything suspicious?”

For a small example, that might even produce a convincing result. But an enterprise investigation is not a single question. It requires evidence collection, entity resolution, contextual interpretation, follow-up questions, and verification.

It also needs to operate across enormous volumes of data without making every investigative decision dependent on an expensive model call.

At Above, we've built a fleet of specialized AI investigative agents that work within an investigation framework.

The framework gives investigators structured access to relevant observations and business context. Different investigative tasks can require different evidence sources, tools, and reasoning.

Imagine that an AI agent unexpectedly retrieves several sensitive customer documents. An investigation might begin by asking which identity was used, which task the agent was performing, and which business objects were involved.

The next question could be whether the documents were relevant to that task. If the activity remains concerning, the investigator may need additional endpoint or application evidence to determine whether the information was staged, transformed, or transferred.

Each step should be motivated by an investigative question.

This architecture allows us to use model reasoning where it adds value, while relying on more structured systems to retrieve data, maintain relationships, and preserve evidence.

It also provides a way to manage the cost and latency of AI investigations at enterprise scale. The model doesn't need to repeatedly ingest the entire telemetry soup to answer a narrow question about a particular action.

4. The Evidence Graph connects the human, the agent, and the outcome

One of the most difficult aspects of synthetic insider risk is attribution.

An employee can instruct an agent. That agent can invoke tools or other agents. Those operations may use delegated human credentials, service identities, or application-specific permissions.

By the time an action reaches Salesforce or Google Drive, the original instruction may be several steps removed.

This is why we built the Evidence Graph. The graph connects the entities involved in an investigation: people, AI agents, identities, applications, devices, business objects, external destinations, and the activities relating them.

Consider this hypothetical investigation: an employee uses Claude Code to prepare a customer analysis. The agent retrieves an account plan from Salesforce, reads related files from Google Drive, and subsequently writes information to a location outside the approved business workflow.

An isolated file-access alert doesn't explain much. The Evidence Graph helps connect the delegated task, the executing agent, the accessed business objects, and the destination of the information.

We can also incorporate related human activity before and after the agent's actions.

That matters because synthetic insiders don't necessarily operate independently of human insiders. An employee may deliberately misuse an agent, accidentally grant excessive permissions, or unknowingly expose the agent to malicious instructions.

The graph helps investigators examine those relationships rather than assigning every action to whichever identity appears in the final log entry.

It also supports Satya's call for independent auditability. A model-generated explanation should be traceable back to the observable activities and relationships that support it.

5. The investigator cannot become its own source of truth

This is where Satya's argument becomes especially relevant to those of us building AI security products. He warns about relying on models to supervise other models, particularly when their reasoning processes are themselves opaque.

That's a legitimate concern. Using AI to investigate AI introduces another layer of model reasoning. We need to design around the possibility that our investigative models will make mistakes, misinterpret evidence, or arrive at unsupported conclusions.

The architectural distinction we care about is between three things.

Evidence: What the underlying systems actually recorded.

Reasoning: The interpretation an investigative model produces from that evidence and its surrounding context.

Authority: Who or what is permitted to act on the resulting findings.

These responsibilities shouldn't collapse into a single opaque model.

The observations collected from enterprise systems must remain available for inspection independently of the AI's conclusions. The reasoning should be accompanied by a defensible timeline and the relevant supporting evidence. And decisions with significant consequences need appropriate oversight and controls.

An AI investigator may identify activity that deserves escalation. That doesn't mean its interpretation should automatically be treated as an established fact about an employee's intentions or an agent's behavior.

This also changes how we think about risk scoring. A useful score needs to reflect the context and evidence behind it. Security teams should be able to understand what made a situation concerning and which observations support that assessment.

Ultimately, the investigator's job is to make the available evidence understandable and actionable.

6. From investigation to response

Satya also emphasizes containment: organizations must be able to restrict or interrupt a model's actions independently of the model itself.

I think this is an essential distinction between the responsibilities of an investigative system and those of the controls enforcing permissions.

Above's role is to investigate behavior, identify meaningful risk, and provide the context needed to respond.

Depending on the environment and available integrations, findings can feed existing security operations platforms, case-management systems, and intervention workflows.

We also support contextual coaching, allowing organizations to guide employees toward safer behavior when risky actions emerge.

An organization may decide that a suspicious agent requires a credential revocation, an access restriction, or an immediate pause. Those actions depend on independently operated enforcement mechanisms.

No investigative model should have to be trusted as the sole source of authority for such decisions.

An effective architecture connects independent observation, contextual investigation, and appropriate response controls while preserving the responsibilities of each layer.

7. A shared framework for synthetic insider investigations

We've also been working with Forscie on the Synthetic Insider Threat Matrix, extending established insider-threat concepts to AI agents.

The framework is useful because it gives investigators a common language for the distinctive properties of synthetic actors.

We can examine the directives and configuration governing an agent, what invoked its behavior, the permissions and tools involved, the conditions limiting visibility, and the adverse outcomes that may follow.

This is especially relevant when investigating agents that operate across multiple environments or under delegated human authority.

The matrix helps organize the questions. The behavioral investigation framework helps gather and correlate the evidence needed to answer them.

These are complementary parts of the same problem.

8. Building security systems that don't require blind trust

We're entering a period where AI agents will increasingly participate in ordinary enterprise processes. They'll write code, retrieve sensitive information, work with customers, modify records, and execute workflows across systems that were originally designed for human users.

Some will run on endpoints. Others will operate entirely in the cloud. Many will move between both.

That environment presents a substantial investigative challenge.

We need to observe actions independently, connect them to the human and synthetic identities involved, understand the surrounding business process, and reconstruct how an outcome occurred.

We also need to use AI to make sense of that complexity without turning the investigative AI into another unquestionable authority.

This is what we've been building at Above.

Satya's essay articulates a principle I believe will become foundational to enterprise AI security: the intelligence performing an action must remain subject to independent observation, verification, and control.

The same principle should govern the AI investigating that action.

We should be able to use increasingly capable intelligence to conduct sophisticated investigations while maintaining confidence in the underlying evidence and retaining human control over consequential decisions.

That's the architecture we're working toward. And it's how I believe AI should investigate AI.