AREG, short for Agent Runtime Exposure Graph, is the runtime security map behind OSuite.
Research update: 5 October 2026. This working research direction for connecting AREG and BAF is unpublished and not peer-reviewed. This entry retains its original June publication date and separates observed evidence, bounded reconstruction, and proposed use in authorization.
Decision records are useful, but isolated records do not answer the question security leaders ask during rollout and incident review: if this agent goes wrong, where can the damage travel?
AREG connects agents, runtime lanes, tools, systems, actions, policy boundaries, approval leases, proof receipts, and closure events into one graph.
Protocol edges and governance gaps
Agent protocols make runtime edges more visible: an MCP call, A2A handoff, ACP message, workflow event, or managed connector invocation can tell the graph how work moved. That is valuable evidence, but it is not the same as governance closure.
AREG treats protocol records as graph edges whose assurance depends on the surrounding control path. If a protocol lane lacks dissent preservation, human escalation, approval binding, proof receipts, or exception ownership, the graph should show that as an evidence gap rather than hiding it behind a green integration status.
What the graph connects
| Node or edge | Product meaning |
|---|---|
| agent | The autonomous or semi-autonomous actor requesting work. |
| runtime lane | The place where action enters OSuite, such as hook, MCP, SDK, workflow, or gateway. |
| action | The canonical action object produced by CAVA. |
| target system | The repository, SaaS object, API, table, customer record, account, or endpoint affected. |
| boundary | Production, customer data, external communication, money, network, privilege, or policy boundary. |
| lease | The BAF Action Gate Lease whose identity, lifecycle, and authority determine whether reuse is valid. |
| proof receipt | Replayable decision evidence, not proof that every downstream effect was captured. |
Current research bounds and their limits
The exposureBounds.js module is research-only. It computes reachability bounds over a finite set of supplied occurrences and declared worlds, not over every program or action an agent might activate. An occurrence identifies one supplied execution stage; a shared action fingerprint is not proof of shared lineage.
The lower bound contains occurrences supported across the declared worlds; it can omit others that are also certain. The upper bound traverses the candidate union and can include paths whose choices are incompatible. Exactness holds only under the module's stated restrictions. Neither bound authenticates collectors or establishes that the real execution belongs to the declared world family.
The module does not establish complete future-program closure. Missing evidence is not evidence of absence. An occurrence outside the upper bound is excluded only within the supplied candidate family, not from all physical executions. Uncaptured effects and omitted candidates remain outside that claim.
Observed attempts, admissions, receiver-confirmed effects, and inferred possibilities must stay distinct. Receiver confirmation supports that effect's observation; it does not prove that other effects were absent. Receipt associations, temporal ordering, and matching fingerprints do not by themselves establish causal ancestry.
Why it matters
Agent security is not only about whether one action was allowed. It is about exposure shape.
An agent with a verified read-only boundary differs from one authorized to write to production, send external messages, and trigger downstream workflows. AREG helps show the supplied evidence for that difference; a sparse graph alone does not establish a harmless agent.
This helps OSuite investigate practical questions within the available evidence:
- —Which agents touch production-adjacent systems?
- —Which actions cross external or customer-data boundaries?
- —Which runtime lanes are unsigned or unverified?
- —Which approval leases are expired, reusable, or missing proof?
- —Which systems are implicated by the supplied reachability model, and what remains unknown if an agent session is compromised?
How it fits OSuite
PCAA supplies final governance authority. CAVA supplies canonical action identity. BAF enforces bounded authorization. AREG supplies exposure evidence and uncertainty about the runtime environment.
A proposed connection would relate state-dependent reachable consequences to BAF lease validation, using declared evidence and explicit uncertainty rather than treating the graph as an authorization oracle. It is not an implemented complete future-program closure predictor. Prediction never grants permission.
An unrelated graph change is not automatically an authorization violation. Safe narrowing is conditional on action identity, lifecycle, authority, and freshness, plus containment in the declared authorization boundary. Missing lineage cannot establish narrowing; changed strict context commitments still require rejection or a separately authorized decision.
Every covered side effect must be mediated before commitment if it is to be prevented, including downstream SaaS operations and nested-agent actions. The graph can document an observed violation, but cannot retroactively stop it. Post hoc detection is not prevention.
The Agent Runtime Security page presents a runtime map, exposure vectors, firewall lanes, readiness indicators, and evidence paths. Those product views must not be read as a claim that the research-only bounds module is deployed as a complete containment system.
ZeroGate and related work
ZeroGate avoids redundant analysis by preparing an Action Pass earlier, while retaining live revocation checks and durable consumption at admission. A graph prediction does not replace those live checks. This update makes no new performance claim; the ZeroGate reading link above provides the existing measurements and their scope.
Zhang et al., Section VII already describe Bind-Enforce-Contain, richer labels, and applicability to SaaS and nested-agent settings. Their closure-bound approval formulation is relevant to reachable consequences, not merely to recording the initial invocation.
Formation-Consistent Dispatch (FCD) already addresses typed effects, formation-scoped authority, lifecycle controls, and a final fence connecting admission to the executing target. Their scope and enforcement obligations are relevant to the working proposal.
