# The three planes of running agents: identity, control, observability Okta issues agent identities before the session. Honeycomb reconstructs agent behavior after the fact. Between them sits the moment of action — the tool call — where the only question that prevents an incident gets decided. A map of the three planes and how they compose. # The three planes of running agents In 2026 the infrastructure vendors arrived at agents from both ends. Okta built [agent identity](/identity-plane-vs-control-plane) — Agent SSO, short-lived credentials brokered at connection time. Honeycomb built [agent observability](https://www.honeycomb.io/blog/honeycomb-launches-agent-observability-full-visibility-agentic-workflows) — Agent Timeline, OpenTelemetry GenAI traces, reconstruction of multi-agent workflows. Both launches are good news, and both draw the same border from opposite sides. Put them on a timeline and the map draws itself: ``` BEFORE the session AT the moment of action AFTER the fact ────────────────────────── ─────────────────────────── ────────────────────────── identity plane control plane observability plane ────────────────────────── ─────────────────────────── ────────────────────────── who is this agent? should THIS call run? what did the agent do? who is the user behind it? allow / ask / deny — which tools, what path, what scopes does it get? on tool + arguments + what broke, what did can we revoke it? session history, with it cost? the decision recorded ────────────────────────── ─────────────────────────── ────────────────────────── Okta Agent SSO / Gateway, agentic control plane Honeycomb, OTel GenAI Auth0, Entra traces, Datadog ``` Three planes, three questions, three tenses. The identity plane's question is settled before anyone knows what the agent will attempt. The observability plane's question is answered after the attempt is history. The middle plane owns the only question whose answer can still change the outcome. ## Why the middle plane is not the sum of the other two It's tempting to think identity plus observability covers it: verified agents in, full traces out. The gap between them is exactly where agent incidents live. **Identity can't see the action.** A scoped, short-lived, perfectly-brokered credential permits every call inside its scope — the routine update and the prompt-injected destructive write carry the same valid token, because scope was decided at grant time. The failure mode that makes agents different from other workloads is that the entity holding the credential is steerable by its own input; the credential stays legitimate while the behavior goes wrong. **Observability can't refuse anything.** A trace is written down unconditionally, after the fact. Honeycomb's Agent Timeline reconstructs "the full decision path" — the *agent's* decisions: which tool it chose, what it did next. It contains no policy decisions, because the observability plane makes none. When the timeline shows the alarm being silenced, the alarm is already silent. **And observability's record has a structural dependency identity shares: it trusts the agent.** OpenTelemetry instrumentation runs inside the process it measures — the agent self-reports its spans. An injected, buggy, or crashing agent misreports or drops its own telemetry at precisely the moment the record matters. The control plane's record is different in kind, not just in content: it's metered at a chokepoint *outside* the thing being measured. Double-entry bookkeeping, applied to agent behavior — the agent's account of itself, reconciled against an independent ledger. [When we ran a full benchmark through the live gateway](/blog/what-2631-policy-decisions-taught-us), the harness silently re-ran ~145 episodes and booked them at $0; the benchmark's own accounting, and the results files, missed all of them. The decision log on the call path was the only witness. So the middle plane contributes two things neither neighbor can: **the verdict** (each call examined against policy while it can still be held — allow, [ask a human](/what-is-runtime-authorization), or deny) and **the independent record of it** (why each action was allowed, attributed to the identity that initiated it — the answer an incident review and an auditor actually ask for). ## How the planes compose The seams are standards, which is why this is a map and not a war. **Identity → control.** The identity plane hands the control plane its principal: an IdP-issued JWT — Okta, Auth0, Entra, [any OIDC provider](/agent-identity) — arrives at the call path as the verified *who*, and every per-call decision and audit row is attributed to it. User → agent → action → verdict, one chain. **Control → observability.** The control plane hands the observability plane its verdicts: decision records can be exported as OpenTelemetry spans — `gen_ai.*` conventions plus the decision attributes — into whatever backend already holds your traces. Your Honeycomb timeline gains the one span type self-instrumentation can't produce: what the policy said, and why. And the independent meter gives the query engine something to reconcile *against*, not just more of the agent's own account. Each plane does a job the others structurally can't. An agent that matters runs behind all three: credentials issued by the identity plane, actions decided and recorded on the control plane, behavior explored in the observability plane. ## The one-question test for each plane Evaluating a vendor in this space? One question per plane sorts everything faster than a feature grid: - *"Can you revoke this agent's access right now?"* — if yes, you're looking at the **identity plane**. - *"Can you hold this specific call — this tool, these arguments — before it runs, and show me why it was allowed after?"* — if yes, the **control plane**. - *"Can you show me every span of what the agent did last Tuesday, and query it by any attribute?"* — if yes, the **observability plane**. A vendor that answers one question well is infrastructure. A vendor that claims all three deserves the follow-up: *at which moment, from which vantage point?* The honest answer is always one plane with exports to the others — which is the architecture you wanted anyway. --- *Related: [What is an Agentic Control Plane?](/what-is-an-agentic-control-plane) · [Agent identity vs. agent control (Okta)](/identity-plane-vs-control-plane) · [What a gateway can actually enforce](/what-a-gateway-can-enforce) · [What an ACP is not](/comparison) · [MCP server controls](/mcp-controls)*