The three altitudes

OGR guards an agent at up to three altitudes. Each sees something the others can't, and each is a different trade-off between richness of intent and adversary-resistance. A single logical action is correlated across all of them by one guard_id, so it yields one composed decision.

Altitude	Where	Sees	Can block?	Adversary-proof?
conversation	LLM request/response	full prompt, completion, tool/MCP definitions	depends on host	no — pre-execution intent
invocation	the agent's tool lifecycle	tool name + arguments, before dispatch	yes	no — sees declared args
execution	the real exec	actual `argv`, env, syscalls, network	yes	depends on the sensor

The altitude is named for the layer, never for the integration that reports it: an eBPF probe, a seccomp sandbox and a framework's own in-process wrapper all assert execution. Which one it was, and therefore whether the agent could have evaded it, is carried separately by sensor — sensor.class is in_process | wrapper | proxy | kernel, weakest to strongest.

Why three, not one

The conversation altitude has the richest intent and provenance (it sees the untrusted web page the model just read), but it's pre-execution — it can't see what the code actually does.
The invocation altitude is cheap, in-process, and can block before a tool runs — but it only sees the declared arguments. An agent can rewrite cat secret into a python one-liner and slip past an argument check.
The execution altitude sees the real open() and connect(). It's the layer that can be adversary-proof — but only with a kernel-class sensor, and it has the least intent (just an argv and an env).

Defense-in-depth means each altitude covers the others' blind spots. In the Hermes plugin, the invocation hook blocks on intent and a real sandbox (srt or OpenShell) enforces on behavior.

Correlation by guard_id

The first altitude to see an action mints a guard_id and propagates it out-of-band (a guard-context that rides alongside the action). Downstream altitudes inherit it, so the Runtime knows the execution-altitude exec and the invocation-altitude tool_call are the same action. A later altitude can only tighten an earlier decision, never loosen it.

That pairing is also how a bypass becomes visible: an execution event from a kernel sensor with no matching invocation event is an agent that ran something it never declared.

Graceful degradation

If an agent has no sandbox (e.g. Hermes' local backend with no srt), OGR still enforces at the invocation altitude — you lose the adversary-proof layer, not the protocol. The verdict records which altitudes were available.

Next: the GuardEvent object — the wire type each altitude emits — and Provenance & guard-context.