Skip to main content

​
Overview

AARM is a specification, not an implementation. The choice of implementation architecture significantly affects security guarantees, deployment complexity, and operational characteristics. The four architectures are defined by what you control:
ArchitectureYou ControlEnforcement PointBypass ResistanceContext RichnessDefer Support
Protocol GatewayNetworkNetworkHighLimitedPartial
SDK / InstrumentationCodeApplicationMediumFullFull
Kernel / eBPFHostKernelVery HighNoneLimited
Vendor IntegrationPolicy onlyVendor runtimeVendor-dependentVendor-dependentLimited–Moderate
eBPF alone cannot satisfy AARM conformance for context-dependent classifications. It must be deployed as a backstop alongside a semantic-aware architecture. See Kernel / eBPF.

​
The Control Hierarchy

Architecture selection depends on what you control:
  1. Full control (self-hosted): All architectures available. Choose based on capability requirements.
  2. Code control (managed infrastructure): Gateway and SDK available. eBPF may not be possible without host access.
  3. Network control only: Gateway is the primary option.
  4. No control (SaaS): Vendor Integration is the only option. If the vendor does not offer hooks, push for support using the specification as leverage.

​
Selecting an Architecture

  • Choose Gateway when you control the network, protocol adoption (e.g., MCP) is high, and minimal agent modification is required. Good balance of enforcement strength and integration simplicity.
  • Choose SDK when you control the agent code, rich context is essential for intent alignment, and your team can maintain the integration. Best for sophisticated intent drift detection and autonomous deferral resolution.
  • Choose eBPF when you control the host, maximum bypass resistance is required, and forbidden action enforcement is the priority. Must be paired with a semantic-aware architecture for AARM conformance.
  • Choose Vendor Integration when the agent is a SaaS product you do not control and the vendor offers synchronous governance hooks. The only option for third-party agents.
For defense-in-depth, combine architectures in a layered deployment.

​
Action Classification Support

Not all architectures can enforce all four action classifications equally:
ClassificationGatewaySDKeBPFVendor
Forbidden✅ Full✅ Full✅ Strong✅ Full
Context-Dependent Deny✅ Good✅ Full⚠️ WeakDepends on context
Context-Dependent Allow⚠️ Partial✅ Full❌ Not feasibleDepends on context
Context-Dependent Defer⚠️ Partial✅ Full⚠️ Limited⚠️ Limited–Moderate

​
All Architectures Must Implement

Regardless of deployment pattern, every AARM architecture implements the same core components: The architectures differ in where these execute, what visibility they have, and who controls the enforcement point.