Observability Requires Proximity

There is a principle that runs through every generation of software observability, from the earliest application performance monitors to the distributed tracing systems that run modern cloud infrastructure: you have to be present where the data is being generated.

You cannot observe a system’s internal state from a distance. You can approximate or infer it, but you cannot observe it. This is completely architectural and not at all philosophical, and it’s going to matter enormously for anyone trying to understand what AI is doing inside their organization.

Proximity is an architectural requirement

We have written, like many others, that observability is not monitoring, which tells you when something happens outside expected bounds. OpenTelemetry defines observability as the ability to understand the internal state of a system from its external outputs. The goal is not just alerting on known actions or failures, but understanding what’s happening inside, including that which you didn’t know to expect.

The definition contains a structural requirement that’s easy to overlook: to understand the internals of something, your instrumentation has to be close enough to capture the signals that describe it. Just like a doctor takes blood work or a mechanic looks under the hood, you need to be present to capture the internal behaviors of a system.

The three pillars of observability (logs, metrics, and traces) all require this. Distributed tracing only works because trace context is propagated across every service boundary involved in a transaction. If a service in the m idle of the chain isn’t instrumented, the trace is broken. You see fragments, not the full picture. IBM has said that observability requires meticulous data collection from every component to adequately determine the what, where, and why of system events.

Proximity to the source of data isn’t a preference, it is an architectural requirement.

AI computer use agents challenge this architecture

Coding and computer use agents like Claude Code, Cursor, and Gemini don’t behave like typical SaaS applications. They run as native processes on the endpoint, accessing local file systems and executing shell commands. They communicate with other local processes via IPC and WebSocket. This architecture creates a hard observability problem for anything that isn’t on the device itself.

Network monitoring and CASB

A cloud access security broker sits between a user and a SaaS provider. This makes it useful for monitoring access to cloud applications and enforcing policies on sanctioned versus unsanctioned services. This can also illuminate when an employee does something out-of-policy with AI like paste company IP or private data into a ChatGPT browser session.

Its position between user and provider is also its fundamental limitation for this particular case. Its primary use case is to monitor security risks and events that occur at runtime, that is during the interaction between the user and the AI service. Locally installed agents, however, don’t cross a network boundary that a CASB or similar tool can inspect, operating specifically on the device and rarely, if ever, touching an inspection layer.

Claude Code and other SDK-based agents don’t make direct HTTP calls. They often use IPC or WebSocket to communicate with a local CLI process, which then contacts the API so meaningful traffic occurs locally before anything crosses the network.

API-side telemetry

To continue with the Anthropic example, they provide an OpenTelemetry schema for Claude Code monitoring, but it’s not a complete observability solution.

Anthropic’s documentation specifies that user prompt content is redacted by default and raw file contents are never included. There are number of defaults that need to to be overridden in order to understand tool input details, but that means it deliberately excludes some of the most observationally meaningful content.

More importantly, API-side telemetry tells you what the model received and what it responded with. It cannot tell you precisely what the agent did next as those events occur specifically on the endpoint after the API response returns. They produce no additional API calls and don’t appear in any log that isn’t coming from the device itself. In analysis done by Harmonic Security, agent activity doesn’t appear in audit logs, compliance API, or data exports. This represents a black box of on-device information.

EDR

An endpoint detection and response tool is closer to the right architecture as it runs on the device, but it wasn’t built for AI observability. Traditional EDR relies upon known patterns such as malware signatures, suspicious process trees, and known techniques or behaviors.

As we’ve discussed, the non-deterministic nature of AI precludes the ability to establish definitive patterns. Further, they operate as the user themselves, inheriting their credentials and often performing standard (albeit autonomous) user actions on their behalf. Distinguishing between normal user behavior and anomalous user behavior becomes increasingly challenging. Moreso when you consider that intent doesn’t need to be malicious for something to go wrong. The concept of using EDR or similar tooling to observe AI assumes everything is inherently a security problem instead of a safety problem. When an agent deletes a user’s emails on their behalf as part of an unrelated prompt, there is no anomalous process signature or binary, it’s a completely normal, seemingly benign operation with real consequences.

AI agents can take legitimate-looking action for a malicious or erroneous reason. The agent is doing what agents are supposed to do. The question is whether the action is authorized, in context, and in-line with the user’s intent, all of which requires capturing and understanding the prompt and the full chain of what followed, all of which is not captured in modern endpoint defensive technology.

The only data that answers real questions lives on the device

When it comes to understanding AI and its usage at your organization, the questions that matter most are:

• What are my employees doing with AI?
• What are agents doing on behalf of my employees?
• Are the outcomes expected and mapped to my priorities?

Every piece of that picture is generated on the endpoint where the employees are working. The prompt originates there. The process tree is spawned there. The file access occurs there and shell commands are run there.

No remote tool can reconstruct this because the data doesn’t exist in an observable form outside of the device. You cannot infer file system activity from network traffic or reconstruct command execution history from API logs.

Why we built Origin on the endpoint

Every gap described here exists because nothing is present to capture what's actually happening. We are building an endpoint-native sensor because that's where the data is, not a representation of it.

To know what agents are running, capture prompt-level insights, and observe the trajectory of those agents, you must be on the device. The same principle that makes distributed tracing require instrumentation at every service boundary applies here. If the layer where the data is generated isn't instrumented, the picture is incomplete.