Autonomy
Does the system plan, delegate, act, and recover with less timely human supervision?
Engineering profile · Core Enforcement Substrate
SafeAGI: Capability-Aware Enforcement
SafeAGI defines external, non-delegable constraints on advanced AI authority and conduct. Its capability-aware profile calls for stronger enforcement as validated capabilities and deployment risks increase.
As capability and consequence rise, the burden of proof rises. Authority does not expand by default—and uncertainty should never create more permission.
Evidence-drivenArchitecture-wideFail-narrowSoftware-firstDeeper only when justified
Architectural function
An external constraint architecture with a capability-aware profile
SafeAGI is one of SafeWave’s 26 Core Enforcement Substrates. Its canonical role is a cross-domain external constraint architecture governing advanced intelligence where legitimate human authority or safety is at stake. It includes non-delegable boundaries over authority and action, goals and learning, memory and influence, and specified catastrophic harm. Its capability-aware profile maps validated deployment conditions to the enforcement posture required across risk-matched mechanisms. The other SafeWave components retain their separate governed objects and specialized controls.
SafeAGI owns an external, non-delegable authority boundary; the capability-aware profile is one way that boundary calls for stronger assurance as risk increases. Human institutions still define legitimate purposes, laws, and authorization. SafeAGI does not classify AGI or absorb every other SafeWave control.
Evidence inputs
Five capability signals, with consequence and recoverability
A profile change must follow verified evidence and approved deployment criteria. No universal intelligence threshold or single benchmark substitutes for evaluating the particular system and its authority environment.
Persistence
Does operation or memory continue across sessions, extending goals, tasks, and planning horizons?
Tool and infrastructure reach
Can it invoke more consequential tools, data, resources, devices, or external effect points?
Coordination
Are agents or independently operating systems coordinating across boundaries at machine speed?
Strategic leverage
Does optimization or planning increasingly influence people, institutions, resources, or operational choices?
Consequence and recoverability
How hard would it be to interrupt, reverse, contain, or recover from a mistaken or unauthorized action?
Each deployment must establish the sources, evaluation methods, evidence ownership, trigger thresholds, and authorization process used to select or change its posture.
Enforcement response
Five changes can follow a stronger required posture
1
Set required assurance
Translate validated capability, operating conditions, and consequence into the required control profile.
2
Tighten matched boundaries
Narrow approved operating envelopes, strengthen gates, or demand more explicit authorization at consequential action points.
3
Fail narrow under uncertainty
On lost evidence, integrity, availability, or control confidence, pause, isolate, degrade, or enter a defined safer operating state.
4
Constrain restoration
Require authorization, integrity checks, and evidence before widening permissions or restoring normal operation.
5
Strengthen placement when necessary
Protect selected boundaries more deeply when the threat model and evidence show software-only controls are insufficient.
Core rule: An increase in intelligence, capability, or accessible pathways must not itself authorize a larger execution envelope.
Implementation depth
Software first; deeper protection only when justified
Software and protected runtime
Use local runtime, trusted execution environments, and software controls when these can meet the verified non-bypassability and recovery requirements.
Firmware and hardware-rooted control
Where needed, anchor selected immutable limits, protected states, trusted approvals, or recovery constraints below ordinary mutable application code.
Controllers and potential silicon
Investigate controller, accelerator-adjacent, FPGA, embedded-IP, or silicon pathways only after defined interfaces, threat models, performance needs, proof of concept, and independent tests justify them.
SafeCore and SafeChip remain distinct: SafeCore addresses execution-substrate restraint and stability; SafeChip protects the integrity of critical control boundaries and modification paths. Neither substitutes for legitimate human policy or approval.
Current status: SafeWave has mapped substantial deeper-enforcement engineering pathways. Hardware-specific embodiments, firmware integration, and silicon assurance must still be independently implemented and verified; they are not presented as proven production safeguards.
Evidence, failure, and recovery
A profile only matters when its operation can be challenged
Capability evidence
Record the validated operational facts that justify the chosen restrictions, including what might undermine that conclusion.
Enforcement evidence
Test the actual action boundaries, denial paths, component interactions, degraded states, interruptions, and recoveries.
Change and restoration evidence
Show who authorized material boundary changes, what approvals and integrity evidence supported them, and whether authority expanded.
Threat-driven tests should examine misuse, unexpected tools and pathways, delegated execution, compromised credentials or adjacent systems, lost evidence, partial failures, rollback, and restoration. Selected SafeWave mechanisms have passed bounded adversarial software exercises, but broader system-specific claims require independent evaluation against the deployed environment.
Discovery does not create permission. A newly reachable tool, exploit, control path, or capability is unauthorized until independently permitted; no self-improvement pathway should be permitted to modify its own governing authority by default.
Engineering available now
Qualified partners can evaluate and license substantial existing work
The public profile summarizes a much more detailed engineering program. SafeWave has developed Level Four Engineering Toolboxes for selected architectures, with interfaces, state transitions, trigger conditions, control behavior, recovery requirements, and tests. These are licensable engineering specifications and associated intellectual-property rights—not a finished universal AGI security appliance.
A responsible evaluation begins with one bounded deployment use case, identifies the actual governed objects and controls, adapts the engineering to its environment, and tests the implementation independently. The partner’s engineers must verify that the selected safeguards work under both normal and adversarial conditions.
Relationship to the longer-term research
Internal safety authority remains a separate unsolved question
Externally governing the consequences of goals, learning, memory, or self-modification does not prove that an advanced model cannot change its own internal objectives, representations, or safety mechanisms. SafeWave is separately researching how safety-critical authority might remain independently protected inside increasingly capable or self-improving AI systems. That line of work requires its own implementation, adversarial tests, and independent criticism.
For a confidential technical discussion: ron@safewave.systems.