Runtime observability for AI agents needs tamper-resistant signals

At a glance

What this is: This is an analysis of how to instrument AI agent runtimes so security teams can trust what the agent actually did, with the key finding that tamper-resistant signals matter more than rich cooperative telemetry.

Why it matters: It matters because IAM, NHI, and AI security teams need evidence that holds up under compromise, especially when agents can manipulate in-process telemetry and obscure the identities and privileges they exercised.

By the numbers:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, making organisations failing to scope AI access properly 4.5x more likely to experience a security incident.

👉 Read ARMO's analysis of runtime observability for AI agents and tamper-resistant signals

Context

AI agent observability is no longer just a debugging problem. Once an agent can select tools, move data, or make infrastructure changes, the core question becomes which telemetry can still be trusted after compromise, especially when the agent itself may influence the signal source.

That is where identity and access control intersect with observability. Security teams need to distinguish between telemetry the workload emits about itself and evidence produced outside the workload's reach, because that difference determines whether an investigation can prove what identity was actually exercised.

The article's starting position is increasingly typical: most observability stacks still favour rich cooperative telemetry, while security teams need evidence-grade signals that survive tampering.

Key questions

Q: What breaks when AI agent observability relies only on in-process telemetry?

A: You lose evidence quality as soon as the workload can influence the collector. In-process SDKs, framework callbacks, and self-reported logs are fine for debugging, but they are weak under compromise because the same agent that causes the event can suppress or falsify the record. Security teams should treat them as context, not proof.

Q: Why do local AI agents complicate identity and access management?

A: They can retain legitimate permissions while changing timing, prioritisation, and action sequence outside human presence. That means the visible identity may remain stable even as the operational behaviour becomes autonomous. IAM teams then lose the simple link between user session, authorisation, and accountability.

Q: How do teams know if AI observability is actually working?

A: It is working when teams can show which change caused a quality shift, which dataset surfaced the issue, and whether the regression was contained before users were affected. If the team cannot trace behaviour across versions, observability is producing logs, not governance evidence.

Q: What should teams do when managed AI services sit outside their cluster boundary?

A: Ingest provider audit logs as first-class security evidence and correlate them with node-level signals from the rest of the environment. Managed services shrink kernel reach, so the provider logs become the boundary record for what happened inside that segment of the execution path.

Technical breakdown

Signal source trust hierarchy in AI agent observability

AI agent observability is only as reliable as the source of the signal. Cooperative telemetry such as framework callbacks, SDK spans, and self-reported logs is useful for debugging but can be skipped, stripped, or falsified by compromised code. Tamper-resistant sources such as kernel-level eBPF and cloud provider audit logs sit outside the workload's control, so they are far better suited to incident response. The practical distinction is simple: one source tells you what the agent said it did, the other shows what it actually did.

Practical implication: classify every observability source by trust level before you depend on it for security evidence.

Why eBPF and audit logs form the evidence layer

Kernel eBPF observes syscalls, file access, process creation, and network activity from inside the Linux kernel, below the application layer. That makes it resistant to in-process tampering, including attempts to suppress framework instrumentation or hide a tool call. Cloud audit logs play the same role for managed services because the provider emits them from the control plane. For AI workloads, that combination creates a baseline evidence layer that survives even when the agent or its framework is compromised.

Practical implication: place kernel sensors and cloud audit ingestion ahead of in-process instrumentation in your security buildout.

Execution graphs and identity mapping need dual-source correlation

A full execution graph does not come from one collector. It emerges when tool-call semantics from framework or proxy capture are correlated with kernel or cloud events that prove the action occurred. Identity mapping follows the same logic. Control-plane IAM shows what permissions exist, but data-plane telemetry shows which service account or token was actually exercised. That gap is where blast radius lives, especially for AI agents that can chain prompts, tools, and API calls in a single workflow.

Practical implication: correlate declared permissions with exercised identity paths, not just with access review records.

Threat narrative

Attacker objective: The attacker wants to hide the agent's real actions, deny accountability, and make incident response rely on evidence the workload itself can manipulate.

1. Entry occurs when an AI agent or its framework is compromised and begins emitting or suppressing telemetry under attacker control.
2. Escalation happens when the attacker relies on cooperative observability sources that can be stripped or falsified, while the real actions continue at the kernel or cloud boundary.
3. Impact is achieved when investigators are left with misleading logs but no trustworthy evidence of the agent's actual tool use, data access, or identity exercised.

NHI Mgmt Group analysis

Tamper resistance is the defining requirement for AI agent observability. Rich telemetry is not automatically useful in a security investigation if the workload can suppress, spoof, or bypass it. AI agent programmes need evidence-grade signals first and semantic context second, because incident response depends on what survives compromise. The practical conclusion is to treat observability as a trust architecture, not a dashboard problem.

Identity mapping is where observability becomes governance. A control plane can show what an agent is allowed to do, but only data-plane evidence shows what it actually did. That is an NHI governance problem as much as an observability problem, because the difference between granted access and exercised access defines blast radius. Practitioners should make exercised identity a first-class signal in AI agent reviews.

Signal-source hierarchy is the right named concept for this category. The article usefully separates tamper-resistant sources from cooperative ones, and that distinction should become standard in agent security programmes. Teams that start by ranking sources by reachability and repudiation risk will make better choices about eBPF, proxy capture, and audit ingestion. The practitioner lesson is to design collection around admissible evidence, not telemetry abundance.

Managed AI services make provider audit logs the minimum viable control plane. When part of the execution path runs outside your cluster, the provider's logs become the boundary evidence for that segment of the chain. That does not remove the need for kernel visibility, but it does change where trustworthy records must come from. Security teams should stop treating managed dashboards as substitutes for audit-grade telemetry.

The security stack for AI agents now overlaps with NHI governance by design. Tool-using agents, service accounts, and workload tokens all create identity paths that can be exercised, hidden, or over-extended. The field should stop treating agent observability as a pure SRE topic because the real issue is how machine identities are evidenced and constrained. Practitioners should align observability with identity governance controls, not just with reliability workflows.

What this signals

Signal-source hierarchy is becoming a core control concept for AI operations. As agent deployments spread, teams will need to decide which telemetry can support forensics, not just troubleshooting. That means putting tamper-resistant sources such as eBPF and cloud audit logs ahead of cooperative traces, then linking them to identity evidence so exercised access can be proven rather than inferred.

AI agent governance now overlaps with NHI governance in practical ways. The same trust problem appears in service accounts, tokens, and workload identities that an agent can use, chain, or abuse. Pairing this observability model with the SPIFFE workload identity specification is one way to tighten the link between runtime identity and security evidence.

Only 44% of organisations have implemented policies for AI agents, according to our 2026 Infrastructure Identity Survey, which means most teams are still designing observability without a governance baseline. The next phase is not more telemetry by default, but better correlation between runtime action, identity exercised, and the records that survive compromise.

For practitioners

• Define a trust hierarchy for all observability sources Classify each signal source as tamper-resistant, partially resistant, cooperative, or repudiable. Use that ranking to decide what can serve as evidence in an incident and what should only enrich context.
• Deploy kernel and audit-log collection before in-process telemetry Prioritise eBPF sensors on nodes and provider audit log ingestion from managed services before you expand framework callbacks or SDK spans. That sequence gives you evidence first and semantic detail second.
• Correlate exercised identity with granted permissions Compare cloud IAM and Kubernetes RBAC entitlements with the service account tokens, API calls, and sessions the agent actually used. This exposes the gap between theoretical access and real blast radius.
• Treat proxy capture as enrichment, not proof Use MCP proxy capture, sidecars, and framework callbacks to explain context, but do not rely on them as sole evidence when the agent may be compromised. Preserve them as secondary records alongside kernel or cloud logs.
• Audit managed AI services for audit-log coverage gaps Verify that CloudTrail, Cloud Audit Logs, or Azure Diagnostic Settings are being ingested and retained for the same retention window as your security logs. If a managed service cannot produce trustworthy logs, you do not yet have full observability.

Key takeaways

• AI agent observability becomes security-grade only when the telemetry source survives compromise.
• Kernel eBPF and cloud audit logs provide evidence that cooperative traces, framework callbacks, and self-reports cannot match.
• Practitioners should govern AI observability as a trust and identity problem, not as a pure instrumentation exercise.

Key terms

• Signal-source Trust: The degree to which a security control can trust the origin of the evidence it receives. If the source of the signal is spoofed, replayed, or manipulated, the control may still function technically while making the wrong decision. That is a trust failure, not just a detection failure.
• Tamper-resistant telemetry: Telemetry generated or enforced outside the observed workload's reach, so the workload cannot easily suppress, falsify, or selectively omit it. In AI agent security, this usually means kernel-level observation or cloud control-plane audit data that can still stand up in an investigation.
• Execution Graph: A record of how an agent or multi-agent workflow made decisions and called tools over time. It is more than an event log because it connects action sequence, policy application, and outcomes, which makes it useful for audit, incident response, and compliance validation.
• Exercised identity: The permissions, tokens, or service accounts an AI system actually used at runtime, not just the access it was granted on paper. This matters because blast radius is defined by what the workload can truly reach, not by what an IAM review says it should reach.

What's in the full article

ARMO's full blog covers the implementation detail this post intentionally leaves for the source:

• Node-level deployment guidance for kernel eBPF collection across containerised AI workloads
• Practical examples of correlating framework events with syscall and network activity
• Provider audit-log coverage for managed AI services such as cloud model and vector platforms

👉 The full ARMO post covers the trust hierarchy, signal-source tiers, and layered observability model in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle control. It helps security practitioners connect runtime evidence to real identity and access decisions across modern infrastructure.