The hardware-assisted memory safety landscape#
Memory safety vulnerabilities account for roughly 70% of exploitable defects in much of the published industry data. Software mitigations — sanitizers, canaries, ASLR, CFI — still matter, but they share a structural weakness: they execute alongside the code they protect and can be defeated by capable attackers.
Hardware-assisted designs move parts of the contract into the ISA, where software cannot simply disable enforcement. The first part of this page is a primer (aligned with our Technology — Memory safety series): MTE, PAC, CET, MPX, and CHERI. The closing section is explicit about AGIACC as a new company: we adopt CHERI-class capability platforms as our primary hardware story where they fit, and we pursue additional research on AI-specific threats and lifecycle integrity. We stand on extensive prior university, government, and industry work; our contribution is to turn that foundation into deployable AI security practice.
Why funders should care: the winner in trusted AI infrastructure is unlikely to be the loudest model company. It is more likely to be the team that solves the hard platform problems others eventually depend on.
Technology Comparison#
| Technology | Vendor | Safety Scope | Detection | Overhead | Deployment Status |
|---|---|---|---|---|---|
| Arm MTE | Arm | Spatial + temporal | Probabilistic (4-bit tags) | ~3–5% | Pixel 8+, iPhone 17, AmpereOne |
| Arm PAC | Arm | Control flow integrity | Cryptographic signing | ~1% | All ARMv8.3+ devices (billions) |
| Intel CET | Intel | Control flow integrity | Shadow stack + IBT | ~1% | Tiger Lake (11th gen+) |
| Intel MPX | Intel | Spatial only | Bounds registers | ~50% | Deprecated (removed 10th gen) |
| CHERI | Cambridge / Arm / RISC-V | Spatial + temporal + compartmentalization | Deterministic capabilities | ~2–5% | Morello (research), CHERIoT, ICENI |
Arm MTE (Memory Tagging Extension)#
Arm’s MTE, introduced in ARMv9, is the most widely deployed hardware memory safety technology. It associates a 4-bit tag with every 16-byte memory granule and every pointer. On each access, hardware compares tags — a mismatch signals a violation.
Strengths: Low overhead, suitable for always-on production deployment. Deployed at scale in Google Pixel and Apple iPhone.
Limitations: Probabilistic (6.7% bypass probability per attempt), vulnerable to tag leakage (CVE-2025-0072 demonstrated MTE bypass via Mali GPU driver), 16-byte granularity misses small overflows.
Arm PAC (Pointer Authentication Codes)#
Available since ARMv8.3, PAC cryptographically signs pointers using unused upper bits. Before a pointer is dereferenced, its signature is verified — tampered pointers trigger a fault.
Strengths: Near-zero overhead, already shipping in billions of devices, effective against ROP/JOP attacks.
Limitations: Does not enforce bounds — a valid pointer can still access out-of-bounds memory. Signing oracle attacks can forge valid PACs under certain conditions.
Intel CET (Control-flow Enforcement Technology)#
CET provides two complementary mechanisms: a Shadow Stack (hardware-maintained copy of return addresses, detecting ROP) and Indirect Branch Tracking (IBT, requiring indirect jumps to land on ENDBRANCH instructions, detecting JOP).
Strengths: Low overhead, transparent to most software, effective against control flow hijacking.
Limitations: Only protects control flow — does not prevent data-only attacks, buffer overflows, or use-after-free. Coarse-grained IBT is being actively researched for advanced bypasses (CFOP techniques).
Intel MPX — A Cautionary Tale#
Intel MPX (2015–2019) was an ambitious attempt at hardware bounds checking. It added dedicated bounds registers and instructions for spatial safety. However, it suffered ~50% performance overhead, high memory consumption for bounds tables, and was eventually found to be bypassable via Meltdown. Intel removed MPX support from 10th-generation processors.
Lesson learned: Hardware memory safety must be architecturally sound, low-overhead, and integrated into the memory model — not bolted on as an afterthought.
CHERI: The Comprehensive Approach#
CHERI (Capability Hardware Enhanced RISC Instructions), developed since 2010 by the University of Cambridge and SRI International, takes a fundamentally different approach. Instead of adding checks alongside existing pointers, CHERI replaces pointers with capabilities — 128-bit unforgeable tokens that encode bounds, permissions, and validity.
Why CHERI Stands Apart#
| Property | MTE | PAC | CET | CHERI |
|---|---|---|---|---|
| Spatial safety | Probabilistic | ✗ | ✗ | Deterministic |
| Temporal safety | Probabilistic | ✗ | ✗ | Deterministic (revocation) |
| Control flow integrity | ✗ | ✓ | ✓ | ✓ (via sealed capabilities) |
| Compartmentalization | ✗ | ✗ | ✗ | ✓ (fine-grained, in-process) |
| Secret-free | ✗ (tags are secrets) | ✗ (keys are secrets) | ✓ | ✓ |
| Bypassable via leaks | Yes | Partially | No | No |
Key Hardware Platforms#
| Platform | Base ISA | Target | Status |
|---|---|---|---|
| Arm Morello | AArch64 | High-performance, research | UK DSbD research boards |
| Microsoft CHERIoT | RISC-V | IoT, embedded | Active development, LowRisc Sunburst |
| SCI ICENI | RISC-V | Secure 32-bit microcontrollers | Commercial product |
| CHERI-RISC-V | RISC-V | General-purpose | Formal specs, FPGA, RISC-V SIG |
Ecosystem and Standardisation#
The CHERI Alliance#
Formed in 2024, the CHERI Alliance unites processor IP vendors, OS developers, toolchain maintainers, and system integrators around bringing CHERI to commercial deployment. The Alliance provides interoperability testing frameworks and coordinates standardisation.
RISC-V Standardisation#
A dedicated CHERI Special Interest Group within RISC-V International is working to formalise CHERI as part of the RISC-V ISA specification. The open, vendor-neutral nature of RISC-V provides a future-proof foundation across embedded, edge, and datacenter markets.
UK Digital Security by Design (DSbD)#
The UK government’s flagship programme has funded:
- Arm Morello — High-performance CHERI demonstrator
- LowRisc Sunburst — CHERIoT development boards
- RESAuto — CHERI-secured automotive systems
- DEFGRID — CHERI-secured utility infrastructure
- Multiple industrial demonstrators in healthcare, telecoms, and defence
International Policy Endorsement#
Hardware-enforced memory safety has gained recognition at the highest policy levels:
- The White House (2024) endorsed CHERI as a hardware solution for memory safety, citing the impracticality of rewriting all legacy code.
- Chinese National Standards specify chip-level trusted computing as the foundation for AI infrastructure security (AI Computing Platform Security Framework).
- EU AI Act requires demonstrable security measures for high-risk AI systems, creating regulatory pull for hardware-enforced approaches.
AGIACC’s research focus (near-term agenda)#
We work at the intersection of capability hardware, AI safety, and autonomous / embodied systems. As a small, new company, our agenda is deliberately focused:
- CHERI and embodied AI — Compartment models, runtime policies, and integration patterns for agents, robotics stacks, and edge inference — where silicon permits.
- Lifecycle integrity (“AI BOM”, informally) — Linking attestation, provenance, and update discipline across models, firmware, and dependencies — still an active research and standards-adjacent topic.
- Measurement and overhead — Honest benchmarking on workloads that matter to partners (latency, power, toolchain friction).
- Toolchain realism — Contributing where we can to compiler, debug, and verification paths that make capability code shippable, not only demonstrable.
- Composed defences — When MTE/PAC-class mitigations and CHERI-style capabilities should sit in the same fleet, and when they should not.
We collaborate with universities, programmes such as DSbD, and industry partners rather than working in isolation. Credibility for a new firm comes from technical precision and reproducible claims — not from marketing superlatives. The commercial objective is straightforward: build a defensible security layer for AI systems that cannot rely on best-effort software controls alone.