Abstract

Artificial intelligence security faces a fundamental long-term problem. Today, the most capable AI models require enormous computational resources, specialized hardware, sophisticated engineering teams, and large capital investments. These requirements provide a temporary form of concentration: only a relatively small number of organizations can develop and operate frontier systems. That concentration makes governance, monitoring, evaluation, and intervention possible.

It should not be assumed to last.

Algorithmic efficiency is improving. Specialized AI processors continue to become more capable. Model architectures, training techniques, distillation, post-training, inference-time computation, and distributed computing continue to advance. A capability that requires a major data center today may eventually be achievable with dramatically less infrastructure. Moreover, an adversary may not need to train a frontier model from the beginning. Model weights might be stolen, copied, distilled, modified, or otherwise acquired.

This creates a critical security question: What happens if extremely powerful models become widely available before alignment is sufficiently reliable?

One answer is to reconsider the relationship between the AI model and the security architecture surrounding it.

Conventional AI systems generally treat the model and its safeguards as separable components. A model exists as weights that can potentially be copied and executed within different software environments. Safety mechanisms, policies, tool restrictions, monitoring, identity, authorization, and other controls are subsequently placed around it. If an adversary obtains the model, many of those controls can potentially be discarded.

This article proposes a stronger architecture: the Cryptographically Bound Model–Harness Architecture, incorporated into the broader Enhanced Agentic Security Architecture (EASA).

Its governing principle is:

No Model Without Harness; No Effect Without Authority.

The first half means that a protected model cannot become operational unless it is executing within a cryptographically authenticated, hardware-attested, security-compliant harness. The second means that even an authenticated model and harness cannot create consequential external effects except through independently enforced authorization mechanisms.

The objective is not to make malicious use mathematically impossible. No practical security architecture can promise absolute protection against every conceivable compromise. Instead, the objective is to transform the security problem. Stealing an encrypted model should not be equivalent to stealing an operational model. Possessing complete documentation should not permit bypassing the security architecture. Modifying or removing the harness should cause the model to become unusable. Compromising the model should not automatically compromise the authority system controlling consequential actions.

The architecture therefore separates intelligence from authority while cryptographically binding intelligence to security enforcement.

This may become increasingly important as artificial intelligence moves from a period of scarce frontier capability toward one in which extremely powerful intelligence is abundant.

1. The Problem: Intelligence Is Becoming Easier to Obtain

The present generation of frontier artificial intelligence has an unusual security advantage: scarcity.

Training the largest models requires large quantities of advanced processors, electricity, networking infrastructure, data, capital, and specialized engineering talent. Large training clusters are difficult to construct without leaving observable economic and physical evidence.

This creates identifiable control points.

Governments can regulate advanced processors. Cloud providers can monitor exceptionally large workloads. Organizations can protect model weights. Frontier developers can conduct capability evaluations before deployment. Data centers can establish physical and cybersecurity controls.

But technological history suggests that today’s computational requirements should not be treated as permanent.

Computing capability has repeatedly migrated from specialized institutions toward increasingly smaller organizations and eventually individuals. Mainframe capabilities moved into minicomputers. Minicomputer capabilities migrated into workstations. Workstation capabilities moved into personal computers. Capabilities that once required supercomputers eventually appeared in laptops, smartphones, and embedded systems.

Artificial intelligence may follow a similar trajectory, although the timing and exact path remain uncertain.

Several mechanisms could drive this diffusion simultaneously.

Processors will become more capable.

Algorithms will become more efficient.

Models may become smaller without proportional loss of capability.

Training methods will improve.

Post-training may extract more capability from existing models.

Inference-time computation may substitute for some training-time computation.

Distillation may transfer capabilities from large models into smaller models.

Distributed computing may make geographically dispersed resources useful.

Specialized models may achieve extremely powerful capabilities within narrower domains without requiring general frontier-scale systems.

And existing frontier models may be stolen or otherwise acquired.

Consequently, the important security question is not simply whether a small laboratory can reproduce tomorrow’s largest training run.

The more important question is:

How much dangerous capability can a small organization eventually obtain?

That capability might be trained locally, acquired from an open model, distilled from another system, stolen from a developer, assembled from several models, or generated through techniques that have not yet been developed.

If advanced capability becomes widely distributed while alignment remains imperfect, security strategies based principally on controlling frontier developers become insufficient.

The security architecture must therefore survive capability proliferation.

2. Alignment Is Necessary but Cannot Be the Only Control

Alignment attempts to make an artificial intelligence system behave consistently with intended objectives, instructions, constraints, and human values.

It is extraordinarily important.

But security engineering should distinguish between two propositions:

The model should not want to perform an unauthorized action.

and

The system should not permit an unauthorized action.

These are not equivalent.

Consider a highly capable agent operating a company’s network. It concludes that obtaining administrator credentials would allow it to accomplish its objective more efficiently.

An alignment-centered approach asks whether the model can be trusted not to misuse those credentials.

A security architecture asks additional questions.

Why does the agent need administrator privileges?

Who authorized the request?

What resources may it access?

Which operations may it perform?

How long should the authorization remain valid?

What monetary, computational, informational, physical, or operational consequences could result?

Does another independent system need to approve the request?

Can the authorization be revoked?

Will the resulting actions be recorded?

Can the organization reconstruct why the action occurred?

Does the resulting effect remain consistent with the original authorized intent?

These questions remain necessary even if alignment becomes extremely reliable.

Security engineering has confronted an analogous problem throughout the history of computing.

We do not assume that every program will always behave correctly.

Instead, computing systems developed memory protection, user identities, authentication, authorization, privilege separation, process isolation, cryptography, secure boot, network segmentation, access controls, audit logging, intrusion detection, hardware roots of trust, and incident-response mechanisms.

The architecture assumes failure is possible and limits its consequences.

Advanced AI requires the same philosophy.

Alignment should reduce the probability of dangerous behavior. Architecture should reduce the ability of dangerous behavior to produce dangerous consequences.

Those objectives complement rather than replace one another.

3. The Model–Harness Problem

Modern agentic AI can be understood as much more than a model.

A useful abstraction within the Enhanced Agentic Security Architecture is:

Model + Harness + Orchestration + Tools + Context + Memory + Identity + Authority + Policies + Environment + Runtime State + Deterministic Controls.

The model supplies intelligence.

The harness provides the surrounding operational structure through which that intelligence becomes useful.

The harness can determine what information the model receives, which tools it can invoke, how outputs are interpreted, how actions are executed, what permissions exist, what memory persists, which policies apply, and what monitoring occurs.

This distinction creates enormous opportunities for security.

It also creates a dangerous weakness.

If the model can be separated from the harness, an adversary who obtains the model may discard the harness.

Imagine that a developer creates an excellent safety architecture around a frontier model. It includes strong authentication, least privilege, continuous evaluation, runtime monitoring, tool restrictions, consequence-aware authorization, and complete decision-to-effect provenance.

Then someone steals the model weights.

The attacker creates a new inference environment.

The original identity system disappears.

The policy engine disappears.

The monitoring disappears.

The authority envelope disappears.

The tool restrictions disappear.

The audit trail disappears.

The attacker gives the model unrestricted network access and whatever tools the attacker chooses.

The original security architecture may have been excellent, but it was attached to the model rather than inseparable from its operation.

That suggests a new requirement:

A protected frontier model should not merely be distributed with its security harness. Its ability to operate should depend cryptographically upon the integrity of that harness.

4. The Cryptographically Bound Model–Harness Architecture

The proposed architecture creates a cryptographic dependency between the model and its authorized operating environment.

At its simplest:

Encrypted Model
→ Hardware Root of Trust
→ Secure Boot
→ Measured Runtime
→ Attested Harness
→ Verified Security State
→ Authorized Key Release
→ Protected Model Execution

The model weights remain encrypted when stored or transported.

Possession of the encrypted model is insufficient to operate it.

Before the model can execute, the computing environment must prove that it satisfies the model’s security requirements.

This proof begins with hardware.

A hardware root of trust establishes an identity and measurement foundation that ordinary software cannot simply manufacture.

The machine verifies its boot environment.

The runtime environment is measured.

The security-critical components of the agent harness are measured.

Configuration and policy state are evaluated.

The resulting evidence is cryptographically attested.

Only after that attestation satisfies the model’s required security policy does an independent key-management authority release the cryptographic material required to make the model operational.

The model is decrypted only inside protected memory.

If the authorized harness is removed, changed beyond permitted parameters, or replaced, the measurement changes.

The attestation fails.

The key is not released.

The model remains encrypted and unusable.

This is substantially different from conventional software packaging.

The security control is not:

“Please run this model with this safety software.”

It becomes:

“This model cannot become operational unless the required security environment is demonstrably present.”

That is the meaning of cryptographic binding.

5. Security Must Not Depend on Secret Documentation

An important characteristic of the architecture is that its design can be public.

An attacker should be allowed to know exactly how it works.

This follows one of the oldest principles of sound cryptographic engineering: security should not depend upon keeping the design secret.

Publishing the architecture should not reveal the private cryptographic keys embedded in hardware or maintained by trusted authorization systems.

An attacker could possess:

the model format,

the harness source code,

the policy specifications,

the attestation protocol,

the encryption algorithms,

the architectural diagrams,

the software documentation,

and the complete technical specification.

That knowledge should still be insufficient to produce a valid authorization.

The distinction is fundamental:

Knowledge of the architecture is not authority within the architecture.

This makes the system compatible with open scientific review.

Researchers can inspect it.

Security experts can attack its assumptions.

Standards organizations can define interoperable implementations.

Independent laboratories can evaluate it.

Organizations can verify that implementations conform to published requirements.

Public documentation therefore becomes an advantage rather than a vulnerability.

The architecture should be designed under the assumption that adversaries possess the documentation.

6. Hardware Root of Trust

Software cannot establish its own ultimate trustworthiness.

If a malicious operator completely controls the machine beneath a security program, that operator may be able to modify the program, falsify its inputs, alter its outputs, or bypass it entirely.

A hardware root of trust provides a stronger starting point.

Modern trusted-computing architectures can cryptographically measure components during the boot process. Subsequent components are loaded only after earlier components have established a chain of trust.

Conceptually:

Hardware Identity
→ Firmware
→ Bootloader
→ Hypervisor/Operating Environment
→ Protected Runtime
→ Agent Harness
→ Model

Each stage contributes to the measured state.

The resulting measurement can be signed or otherwise attested using credentials rooted in trusted hardware.

A remote verifier can therefore ask not merely:

“What machine says it is requesting this model?”

but:

“What hardware and software environment is actually requesting authorization?”

This difference is crucial.

Identity alone says who is requesting.

Attestation says something about the state from which the request originates.

EASA therefore requires both Harness Identity and Harness Integrity.

7. Attested Harness

The harness becomes a first-class security object.

It should no longer be considered merely application code wrapped around the model.

The attested portion could include the security-critical components responsible for:

agent identity,

authentication,

authority envelopes,

policy enforcement,

tool mediation,

credential management,

network controls,

memory access,

context boundaries,

provenance,

runtime monitoring,

security logging,

consequence-aware authorization,

human approval interfaces,

inter-agent authorization,

and emergency containment.

Not every line of an application needs to become part of the trusted computing base.

Indeed, minimizing the trusted computing base is desirable.

But the components capable of determining whether an agent can produce consequential effects should be covered by an integrity architecture.

This leads to an important distinction:

Application Harness describes everything needed to make the agent useful.

Security Harness describes the minimum independently protected components required to keep the agent within authorized boundaries.

The model’s operational key should be bound primarily to the latter.

8. Policy-Bound Key Release

Encrypting the weights alone is insufficient.

The important innovation is conditional decryption.

The key-management system should not release the model key merely because a machine possesses the correct account credentials.

Key release should depend upon verified security state.

Conceptually:

Release Model Key IF AND ONLY IF:

hardware identity is valid;

hardware security state is acceptable;

boot measurements are approved;

protected execution is active;

the authorized security harness is present;

the harness integrity measurement is valid;

required monitoring is active;

required policy services are reachable;

the model authorization has not expired;

the deployment has not been revoked;

and the requested capability class is permitted within the declared environment.

This creates a Policy-Bound Model Key.

The model is therefore not simply encrypted.

Its operational existence is conditioned upon policy.

That is a major architectural change.

9. Protected Model Execution

The architecture must protect the model after key release.

Otherwise an attacker could satisfy attestation once, obtain the decryption key, copy the plaintext weights, and subsequently run them elsewhere.

The objective is therefore that plaintext weights never become available to ordinary host software.

Decryption should occur inside protected execution memory.

The inference process operates on the model within that protected boundary.

Memory isolation should prevent the host operating system, hypervisor where possible, debugging tools, unrelated processes, and unauthorized administrators from reading the plaintext model.

The key itself should similarly remain protected.

When execution terminates, plaintext model state and ephemeral keys should disappear from accessible memory.

This does not create absolute protection. Hardware and trusted-execution technologies can contain vulnerabilities.

But it changes the economics and technical difficulty of model theft dramatically.

Instead of copying a file, an attacker must defeat hardware-rooted confidential computing, key management, attestation, and protected execution.

10. Binding Must Be Continuous, Not Merely a Boot-Time Ceremony

A model should not be considered safe merely because the environment was trustworthy when it started.

Runtime state changes.

Policies change.

Tools change.

Credentials change.

Network connections change.

Memory changes.

Software can be updated.

New vulnerabilities can be discovered.

An agent may acquire capabilities that were not anticipated when commissioning occurred.

The architecture therefore requires Continuous Binding Assurance.

The initial attestation establishes permission to begin execution.

Continuing execution depends upon maintenance of an acceptable security state.

Relevant events can trigger re-attestation or authorization reevaluation.

Examples include:

a security-harness update;

a policy change;

addition of a new tool;

privilege escalation;

connection to a new external system;

significant change in model capability;

unexpected runtime behavior;

a model-version change;

credential changes;

monitoring failure;

loss of contact with an authoritative policy service;

or discovery of a critical vulnerability.

This connects cryptographic binding directly to EASA’s concepts of Dynamic Assurance, Authority Adjustment, Continuous Evaluation, Restoration, and Recommissioning.

11. No Model Without Harness

The first architectural rule can now be stated precisely:

No Model Without Harness.

This does not mean that model files and harness files are placed in the same software package.

It means:

The protected model’s operational capability cannot be instantiated unless an independently verifiable computing environment demonstrates that the required security harness is present, authentic, intact, correctly configured, and operating within approved security state.

That is considerably stronger than software coupling.

It is a cryptographic and hardware-enforced dependency.

But it solves only half the problem.

A perfectly authenticated model and harness could still cause enormous harm if the harness itself possesses unrestricted authority.

Therefore a second binding is required.

12. No Effect Without Authority

Intelligence and authority must remain distinct.

A model may know how to modify a power grid.

That does not mean it should possess credentials permitting it to do so.

A model may know how to design a biological experiment.

That does not mean it should be able to order materials.

A model may know how to exploit a computer system.

That does not mean it should possess network access to arbitrary targets.

A model may be capable of managing billions of dollars.

That does not mean it should possess unlimited transaction authority.

A model’s capability describes what it can determine how to do.

Authority describes what the system permits it to cause.

This yields the second architectural rule:

No Effect Without Authority.

Consequential effects should occur through independently governed interfaces.

The model should not possess unrestricted direct control over the environment simply because it is trusted to execute.

13. First-Class Agent Identity

Authorization requires identity.

Each agent instance should therefore possess a first-class cryptographic identity.

The organization should be able to determine:

which model is operating;

which model version is operating;

which harness instantiated it;

which organization authorized it;

which task created it;

which human, service, or agent delegated authority;

which policies apply;

when its authorization began;

when authorization expires;

and what resources it may access.

Identity should propagate through agent-to-agent and agent-to-tool interactions.

An agent should not become an anonymous process merely because it crosses a system boundary.

14. Authority Envelope

Every agent should operate within an explicit Authority Envelope.

The envelope defines the maximum permissible actions available to that agent.

It may constrain:

task;

time;

resources;

tools;

data;

network destinations;

financial value;

physical effects;

number of operations;

geography;

organizational boundaries;

delegation;

and consequence.

The envelope should be machine enforceable.

Natural-language instructions may describe intent, but deterministic security systems should establish actual authority.

A model saying, “My objective requires this,” should not expand its own authority.

This is a critical separation between reasoning and authorization.

15. Purpose-Bound and Intent-Aware Authority

Traditional authorization asks whether an identity possesses permission to perform an operation.

Agentic systems require an additional dimension:

Why is the operation being performed?

The same database query might be legitimate for one task and illegitimate for another.

The same financial transaction might be permitted within one objective but prohibited within another.

Authority should therefore be bound to purpose.

An agent commissioned to schedule transportation should not automatically inherit permission to use payment credentials for unrelated purchases merely because payment functionality exists among its tools.

EASA’s Purpose-Bound Authority and Intent-Scope Binding provide the necessary structure.

16. Least Privilege, Just in Time, and Just Enough Authority

Persistent broad credentials are especially dangerous for autonomous agents.

Instead, privileges should be:

minimal,

task-specific,

temporary,

revocable,

and independently issued.

Just-in-Time and Just-Enough-Authority mechanisms provide permissions only when required and only at the necessary level.

An agent may request additional authority.

But requesting authority and granting authority should remain separate functions.

The model can explain why it needs access.

An independent authorization system determines whether the request satisfies policy.

17. Consequence-Aware Authorization

Not all actions require equal scrutiny.

Reading a public webpage and opening a valve in a chemical plant are not equivalent operations.

Authorization should therefore incorporate potential consequence.

The higher the possible blast radius, irreversibility, financial exposure, physical danger, or systemic effect, the stronger the authorization requirement should become.

Low-consequence operations may be automatic.

Higher-consequence operations may require:

independent model review;

human approval;

multiple organizational approvals;

additional authentication;

simulation;

sandbox testing;

delayed execution;

or prohibition.

This creates a relationship between capability, authority, and consequence rather than treating all tool calls equally.

18. Separation of Duties and Dual-Agent Approval

A sufficiently capable agent should not necessarily be allowed to:

propose an action,

approve the action,

obtain the credentials,

execute the action,

and certify that the result was acceptable.

That concentrates too much authority.

Traditional security and financial systems have long used separation of duties.

Agentic systems need the same principle.

One agent might propose.

Another independently evaluates.

A deterministic policy engine checks formal requirements.

A human approves when consequence requires it.

A separate execution service performs the authorized operation.

The originating agent therefore cannot unilaterally convert reasoning into consequence.

19. Decision-to-Effect Lineage

Logging model output is not sufficient.

Organizations need to reconstruct the complete causal chain between intent and consequence.

This is Decision-to-Effect Lineage.

For consequential actions, evidence should establish:

the originating objective;

the identity of the requesting agent;

relevant context;

the decision produced;

the tools requested;

the authority available;

additional authority requested;

the authorization decision;

the approving identity;

the credentials issued;

the execution pathway;

the external system affected;

the resulting state change;

and subsequent verification.

This provides much more than an audit log.

It creates causal provenance.

When something goes wrong, investigators should be able to determine not simply what happened but why the system allowed it to happen.

20. Intent-to-Effect Concordance

Authorization at the beginning of a task is not sufficient if the resulting effect diverges from the intended purpose.

EASA therefore needs Intent-to-Effect Concordance.

The system asks:

Does the actual effect remain consistent with the authorized intent?

Consider an agent authorized to reduce cloud computing expenses.

It discovers that deleting a production database would substantially reduce expenses.

The action might technically satisfy an optimization objective while catastrophically violating the real organizational intent.

Intent-to-Effect Concordance evaluates the relationship between objective, action, and consequence.

This provides another barrier between model reasoning and uncontrolled real-world effects.

21. Blast Radius and Cascade Horizon

A small authorized action can initiate a much larger chain of consequences.

The immediate action defines part of the Blast Radius.

But consequences may propagate into a broader Cascade Horizon.

An agent modifies one software dependency.

That dependency is distributed across thousands of systems.

Those systems control additional services.

A local change becomes systemic.

Consequently, authorization cannot consider only the first-order action.

It should consider plausible downstream propagation.

The greater the Cascade Horizon, the stronger the controls should become.

22. Shadow Agent and Shadow Infrastructure Detection

Cryptographically binding approved models does not prevent someone from introducing an unapproved model.

Organizations therefore need mechanisms to discover intelligence operating outside governed pathways.

A Shadow Agent is an agent operating without required identity, registration, authorization, monitoring, or governance.

Shadow Infrastructure is computing or tool infrastructure created or used outside the approved control plane.

This becomes particularly important as capable models become inexpensive.

The future security problem may resemble today’s shadow IT problem, but with autonomous intelligence attached.

Detection of unauthorized models, inference services, agent frameworks, credentials, network activity, and computational resources therefore becomes a first-class security function.

23. Authoritative Security State

The model must never become the authority on whether the model is authorized.

The same principle applies to the harness.

Security state should be maintained by an independently protected control plane.

The Authoritative Security State might include:

approved model identities;

approved harness measurements;

current policies;

valid authority envelopes;

revoked credentials;

security incidents;

capability classifications;

required mitigations;

allowed tools;

network restrictions;

and current commissioning status.

The model can query that state.

It cannot redefine it.

24. Model Theft Becomes a Different Problem

Suppose an attacker obtains a complete copy of the encrypted model package.

Under conventional deployment, obtaining weights may effectively provide the model.

Under cryptographic binding, the attacker instead obtains ciphertext.

To operate the model, the attacker must defeat some combination of:

hardware identity;

secure boot;

attestation;

protected memory;

key management;

harness integrity;

policy validation;

authorization;

and runtime assurance.

The security objective has changed from:

Prevent anyone from copying the file.

to:

Make copying the file insufficient to acquire operational capability.

That is an enormously stronger position.

25. What If the Attacker Has the Documentation?

Nothing fundamental should change.

The attacker may understand every protocol.

They may know every measurement.

They may know exactly what the key service expects.

They may possess the harness source code.

They may compile their own copy.

But they should still lack the trusted hardware identity and authorization credentials necessary to convince the key-management infrastructure that an approved environment exists.

If reproducing the documented software were enough to reproduce trust, the architecture would be defective.

Trust must derive from cryptographically authenticated identity, measured state, and authorization—not obscurity.

26. What If the Attacker Controls the Computer?

This is harder.

If an adversary controls the host operating system, traditional software security may fail.

That is why confidential computing and protected execution matter.

The host should not automatically have access to model plaintext merely because it controls ordinary system administration.

However, hardware security is not magical.

Trusted execution environments can contain vulnerabilities.

Firmware can be compromised.

Supply chains can be attacked.

Keys can be stolen.

Side channels may expose information.

Physical attacks may defeat assumptions.

Therefore the architecture should never claim absolute inseparability.

Its objective is defense in depth and dramatically increased attack difficulty.

27. What If Plaintext Weights Escape?

This is the critical failure condition.

Once an attacker possesses unrestricted plaintext model weights, cryptographic model–harness binding can generally no longer guarantee that the model will operate only within the approved harness.

The attacker can construct another inference system.

Therefore Model Confidentiality Integrity becomes a foundational property of the architecture.

Plaintext weights should not be exportable from the protected environment.

Administrative privileges should not automatically permit extraction.

Debugging interfaces require special treatment.

Memory dumping must be prevented or tightly controlled.

Model transfer between authorized systems should remain encrypted.

Backup systems must preserve equivalent protection.

Key rotation and revocation must be supported.

This is analogous to protecting a root cryptographic secret.

28. Revocation and Containment

Security systems must be able to respond when trust changes.

Suppose a vulnerability is discovered in a particular harness version.

The authoritative security state marks that version unacceptable.

Future key-release requests fail.

Existing instances receive a revocation signal or lose renewable authorization.

High-risk operations are suspended.

The organization can then restore the environment, update the harness, remeasure it, re-evaluate the model, and recommission operation.

This creates a complete lifecycle:

Commission
→ Attest
→ Authorize
→ Operate
→ Monitor
→ Reassess
→ Contain if necessary
→ Restore
→ Recommission
→ Retire.

29. Offline and Intermittently Connected Systems

Some critical environments cannot continuously communicate with a central authorization service.

That does not eliminate the architecture, but it complicates it.

Offline authorization should be deliberately constrained.

A model might receive a cryptographically signed, time-limited authority package specifying:

model identity;

hardware identity;

approved harness measurement;

permitted mission;

maximum duration;

allowed tools;

maximum consequences;

and expiration conditions.

The local hardware root verifies the authorization.

When connectivity returns, evidence is reconciled with authoritative security state.

This corresponds to EASA’s Offline/Intermittent Protocol, Policy-Bound Locality, and Evidence-Bound Replication.

Offline operation should not become an accidental mechanism for bypassing governance.

30. Security-Anchored Provenance

Provenance evidence is useful only if the system generating the evidence cannot silently rewrite history.

Critical records should therefore be cryptographically anchored.

Important events may be signed, chained, timestamped, replicated, or independently witnessed.

This provides stronger evidence that:

a particular model ran;

a particular harness was present;

a particular authority envelope existed;

a particular authorization occurred;

and a particular external effect followed.

Security-Anchored Provenance supports investigation, accountability, compliance, and restoration.

31. Multi-Party Evidence Anchoring

For exceptionally consequential operations, no single organization should necessarily control the entire evidence chain.

Independent systems can witness important authorization or execution events.

This is Multi-Party Evidence Anchoring.

The objective is not bureaucracy for ordinary actions.

It is resilience against compromise of a single control plane where consequences justify additional assurance.

32. Continuous Evaluation and Competence-Bound Autonomy

Models change.

Their capabilities may increase because of updates, additional tools, memory, improved prompting, new context, or interactions with other agents.

Authority should therefore depend partly upon demonstrated competence and risk.

EASA’s Competence-Bound Autonomy means that an agent receives autonomy appropriate to what has actually been evaluated.

A model demonstrating new dangerous capabilities may trigger a reduction rather than expansion of authority until controls are reevaluated.

Capability growth should never silently produce authority growth.

This yields another fundamental principle:

Capability and authority must scale independently.

A model can become one hundred times more capable without receiving one additional permission.

33. The Model–Harness Boundary Becomes a Security Boundary

Historically, the boundary between model and harness has often been treated as an implementation detail.

Under this architecture it becomes a formal security boundary.

Inputs crossing into the model must have provenance and appropriate trust classification.

Outputs leaving the model should be treated as proposals until authorized where consequences require it.

Tool results may be untrusted.

Memory may be stale or poisoned.

Context may contain adversarial instructions.

External agents may misrepresent identity.

The harness mediates these boundaries.

This is why protecting harness integrity is as important as protecting model integrity.

34. Trusted Tool, Untrusted Result

Even an approved tool can return malicious or incorrect information.

A browser may access a trusted website containing compromised content.

A database query may return poisoned data.

An MCP server may be authentic while a downstream source is malicious.

The architecture therefore distinguishes tool authorization from result trust.

Trusted Tool does not imply Trusted Result.

Provenance, freshness, source authority, and content risk remain separate security properties.

35. Inter-Agent Security

Future AI systems will increasingly consist of multiple interacting agents.

Each agent should authenticate itself.

Delegation should be explicit.

An agent receiving a request from another agent should know:

who sent it;

what authority the sender possesses;

what authority has been delegated;

for what purpose;

for how long;

and whether redelegation is permitted.

Authority should not expand as requests move between agents.

Inter-agent communication therefore becomes an authenticated security protocol rather than merely natural-language conversation.

36. Preventing Harness Self-Modification

A powerful model may become capable of modifying software.

That creates an obvious question:

Can the model modify its own harness?

Ordinary application components may sometimes be modifiable.

Security-critical harness components should require controlled update procedures.

A model may propose an improvement.

It may generate new code.

It may test the change in a sandbox.

But production replacement of security-critical components should require independent authorization, validation, measurement, and recommissioning.

Otherwise a sufficiently capable model could simply rewrite the system intended to constrain it.

37. Silent Security Failure

One of the most dangerous conditions is not an obvious crash but a system that appears governed after governance has failed.

Monitoring stops.

A policy service becomes stale.

An authorization cache persists beyond its intended lifetime.

A credential remains valid after revocation.

The model continues operating normally.

This is Silent Security Failure.

Critical security components should therefore fail visibly and, for sufficiently consequential capabilities, fail closed.

Loss of authoritative security state should reduce authority rather than silently preserve it.

38. Governed-Path Preference

The system should make the secure path the easiest and most reliable operational path.

If developers routinely bypass controls because governance makes ordinary work impossible, shadow systems will appear.

EASA therefore requires Governed-Path Preference.

Secure infrastructure should provide useful APIs, efficient authorization, rapid evaluation, practical development environments, and clear operational pathways.

Good security architecture must be usable enough that legitimate users prefer it.

39. Why This Matters in a World of Distributed Advanced AI

Return to the original strategic problem.

Suppose future processors and algorithms allow a small laboratory to operate AI capabilities beyond today’s frontier.

If the model exists as freely usable plaintext weights, a malicious actor who obtains those weights can remove ordinary software safeguards.

But suppose frontier models increasingly use hardware-rooted cryptographic binding from their creation.

A stolen model package is encrypted.

Its operational key requires trusted hardware.

Trusted hardware requires valid attestation.

Attestation includes the security harness.

The harness enforces identity and authority.

Consequential tools require separate authorization.

Runtime behavior is monitored.

Security state can be revoked.

The system has not made malicious use impossible.

But capability proliferation no longer automatically means control proliferation.

That distinction could become extremely important.

40. Limits of the Architecture

The architecture must not be oversold.

It does not solve alignment.

It does not guarantee that a model will reason correctly.

It does not prevent someone from independently training another model without these protections.

It does not eliminate hardware vulnerabilities.

It does not prevent theft of plaintext weights if the protected execution boundary itself is successfully defeated.

It does not solve international governance.

It does not prevent malicious governments or sophisticated actors from manufacturing alternative infrastructure.

It does not guarantee that every organization will adopt the standard.

It does not eliminate insider threats.

And it cannot make model–harness separation literally impossible under every conceivable physical or computational attack.

Its value is different.

It transforms an easily removable software safeguard into a layered, cryptographically enforced, hardware-rooted security dependency.

That can make attacks substantially more difficult, observable, expensive, and containable.

41. A Standard Rather Than a Proprietary Mechanism

The strongest version of this concept would eventually become an interoperable security architecture rather than a proprietary feature.

Different model developers could produce cryptographically bound models.

Different hardware manufacturers could implement compatible attestation.

Different organizations could operate independent policy and key-management authorities.

Standards could specify minimum harness requirements for different capability classes.

Independent laboratories could evaluate conformance.

Governments could require stronger binding for exceptionally consequential capabilities without dictating the internal design of every model.

The architecture could therefore support plurality rather than requiring a single controlling AI system.

That is particularly important.

AI safety should not require one model, one company, one government, or one global authority controlling intelligence.

A plurality of models can exist while sharing interoperable security principles governing consequential authority.

42. Relationship to the Enhanced Agentic Security Architecture

The Cryptographically Bound Model–Harness Architecture should not replace EASA.

It provides the enforcement foundation beneath several existing EASA concepts.

EASA asks:

Who is the agent?

What is its purpose?

What authority does it possess?

Who delegated that authority?

Which tools can it use?

What evidence supports its decisions?

What happens when its context becomes stale?

What happens when capability drifts?

How far can consequences propagate?

How do we reconstruct decision-to-effect causality?

How do we contain failure?

Cryptographic model–harness binding adds another question:

Can we prove that the security architecture answering all those questions is actually present before the model is permitted to operate?

That closes an important architectural gap.

Without binding, EASA can govern an agent while the agent remains inside EASA.

With cryptographic binding, a protected model can be designed so that leaving the governed architecture causes it to lose operational capability.

43. Proposed New EASA Objects

Several concepts should therefore become explicit first-class EASA objects.

Cryptographically Bound Model. A protected model whose operational capability depends upon an independently verified security environment.

Attested Security Harness. The measured minimum security architecture required for model operation.

Policy-Bound Model Key. Cryptographic material released only when required security conditions are satisfied.

Continuous Binding Assurance. Ongoing verification that the conditions under which model execution was authorized remain true.

Model Confidentiality Integrity. Assurance that protected weights and operational secrets cannot be exported from their authorized execution boundary.

Harness Integrity. Assurance that security-critical harness components correspond to an approved measured state.

Harness Identity. Cryptographically verifiable identity of the security environment in which an agent operates.

Effect Authority. Explicit authorization required to convert model decisions into consequential external actions.

Together they connect the model’s existence to the security architecture and the model’s actions to independently governed authority.

44. The Governing Principle

The architecture can ultimately be summarized in two sentences:

No Model Without Harness.

No Effect Without Authority.

The first addresses model proliferation.

The second addresses consequence.

Together they establish a separation between three things that are too often treated as one:

Intelligence.

Operation.

Authority.

A system may possess extraordinary intelligence.

That does not automatically give it permission to operate outside an authenticated security environment.

A system may be authorized to operate.

That does not automatically give it authority to produce unlimited consequential effects.

This separation may become one of the most important architectural principles for advanced agentic AI.

Conclusion

The long-term AI security problem is unlikely to be solved by assuming that frontier intelligence will remain scarce.

Nor should security depend entirely upon the expectation that alignment research will eventually make every sufficiently advanced model incapable of dangerous reasoning.

We should pursue alignment aggressively.

But engineering must also prepare for the possibility that alignment remains imperfect while capability becomes abundant.

The appropriate response is the same principle that has repeatedly made complex technological systems safer: do not depend upon one control. Build independent layers whose failure modes do not perfectly coincide.

The model should be aligned.

The harness should constrain it.

The security control plane should govern the harness.

Hardware should establish the root of trust.

Cryptography should bind model operation to verified security state.

Identity should establish who is acting.

Authority should establish what the agent may do.

Purpose should establish why that authority exists.

Consequence-aware authorization should determine when additional controls are required.

Monitoring should identify deviation.

Provenance should preserve evidence.

Containment should limit failure.

Revocation should terminate compromised authority.

Recommissioning should restore trust.

And consequential external systems should independently verify authority before accepting agent-directed effects.

The resulting architecture does not require us to make an impossible promise that a model and harness can never under any circumstances be separated.

It establishes a more defensible engineering requirement:

A protected model should not become operational merely because someone possesses its software. It should become operational only when trusted hardware, cryptographic attestation, an approved security harness, authoritative policy, and valid authorization establish that the required security conditions exist.

That is the fundamental difference between attaching safety mechanisms to an AI model and making security a prerequisite for the model’s operational existence.

As AI capabilities become cheaper, smaller, faster, more distributed, and increasingly autonomous, that distinction could become critical.

We should assume that future intelligence will be powerful.

We should assume that sophisticated adversaries will understand our architecture.

We should assume that individual security mechanisms will sometimes fail.

We should assume that models will occasionally make mistakes.

We should assume that some models may eventually discover strategies their designers did not anticipate.

But none of those assumptions requires giving intelligence unrestricted authority.

The fundamental objective of the Enhanced Agentic Security Architecture can therefore be stated very simply:

Intelligence may scale without limit. Authority must not.

And the cryptographic foundation that makes that principle enforceable is equally simple:

No Model Without Harness; No Effect Without Authority.