I went down a pretty weird rabbit hole today.

It started with AI security.

My first thought was: if AI keeps getting smarter, eventually does it need to run inside some kind of encrypted framework that the AI itself can't understand?

That sounds reasonable for about five minutes.

Then I realized the problem.

If your security depends on AI not being smart enough to understand the system, you've already built the security system around a losing assumption.

Eventually something will understand it.

A human.

A reverse-engineering system.

An AI.

Or some combination of all three.

So I started thinking about the problem differently.

What if the security system doesn't need to stay secret?

What if the attacker can understand exactly how it works...

...but the actual computer they're trying to understand doesn't stay the same long enough for that knowledge to remain useful?

And what if that wasn't just an AI security layer?

What if that was the computer?

The idea isn't encrypted AI. It's a morphic computer.

The first version of this thought experiment was basically an encrypted programming language.

Take Python:

x = 5
y = 10
print(x + y)

Transform it into something else:

J7 5
R2 10
K9 J7 R2

Where, for this particular runtime:

J7 = store
R2 = store
K9 = add and output

The program still produces 15.

Its meaning hasn't changed.

Its representation has.

Now throw that representation away and generate another one:

Q4 5
B8 10
Z1 Q4 B8

Same program.

Same result.

Different executable representation.

That is already interesting.

But then I realized Python isn't really the point.

Why stop at the programming language?

The much bigger idea is:

What if stable software semantics ran on top of a continuously changing cryptographic execution substrate?

Not just AI.

Everything.

Applications
AI systems
Databases
Browsers
Services
Operating system
Drivers
Networking
Memory
        │
        ▼
MORPHIC COMPUTING FABRIC
        │
        ▼
Hardware root of trust

The software still behaves consistently from the outside.

Internally, however, the machine is constantly changing how that behavior is represented and executed.

I assumed this was mostly science fiction.

Then I found MORPHEUS.

DARPA launched the System Security Integrated Through Hardware and Firmware — SSITH — program in 2017 because the traditional security model was becoming an endless cycle of finding vulnerabilities and patching them.

DARPA described the situation pretty accurately as "patch and pray."

Researchers at the University of Michigan, along with collaborators from Princeton and the University of Texas at Austin, took a very different approach.

They built MORPHEUS.

MORPHEUS was publicly presented in 2019 as a RISC-V processor architecture built around moving-target defenses and something the researchers call churn.

The idea is surprisingly close to this thought experiment.

Instead of trying to guarantee that every vulnerability has been eliminated, MORPHEUS continuously changes information an attacker needs in order to exploit those vulnerabilities.

That includes things such as:

pointer representations

code locations

data locations

encryption keys

randomized mappings

And then it changes them again.

And again.

In their 2019 simulated RISC-V prototype, the researchers evaluated a churn period of about 50 milliseconds.

Twenty times per second.

Their attack model estimated that this was at least 5,000 times faster than the time needed to penetrate the protected state they were targeting. On the SPEC’06 and MiBench benchmarks in that simulated configuration, they reported roughly 1% average slowdown and 7% worst-case slowdown. These are results for the paper’s specific design and threat model, not measurements of an entire morphic software stack. Read the original MORPHEUS paper.

That changes the security problem.

The attacker doesn't just need to find a vulnerability anymore.

They need to:

find the vulnerability
        ↓
probe the machine
        ↓
understand the current state
        ↓
construct the exploit
        ↓
execute the exploit

before:

REKEY
REMAP
RE-RANDOMIZE

happens again.

That is a completely different kind of fight.

MORPHEUS isn't the only prior art

Once I started looking, I found several earlier ideas pointing in the same general direction.

Instruction-Set Randomization

Researchers were exploring instruction-set randomization more than twenty years ago.

The basic idea was almost literally:

Give each running system its own language.

Injected malicious machine code wouldn't work because the attacker's instructions were written for the wrong instruction set.

There were even implementations using encrypted binaries and AES-based instruction randomization.

The concept is incredibly relevant here:

normal ISA
    ↓
secret/randomized ISA
    ↓
execute

There were also attacks against early ISR systems, which is important.

Static randomization isn't enough.

If an attacker can spend enough time recovering the mapping or key, the protection starts falling apart.

Which leads directly to the next idea.

Continuous re-randomization

In 2016 researchers presented Shuffler, a system that continuously moved code around during execution.

Instead of randomizing the program once at startup, Shuffler repeatedly re-randomized code locations on the order of milliseconds.

The paper explicitly describes this as creating a real-time deadline on the attacker.

That's basically the phrase I've been circling around.

Security becomes temporal.

Knowledge has an expiration date.

Dynamic software diversity

Other research has explored generating different implementations of the same computation and randomly switching between them.

Meaning:

Implementation A ─┐
Implementation B ─┤
Implementation C ─┼─ same result
Implementation D ─┤
Implementation E ─┘

Different machine behavior.

Same program semantics.

Again:

Stable meaning. Unstable implementation.

That seems like the important abstraction.

So what am I actually proposing?

I'm definitely not claiming I just invented moving-target defense, instruction-set randomization, software diversity or MORPHEUS.

Those fields already exist.

The question I'm interested in is what happens when you stop treating them as individual security techniques and start treating the underlying principle as the architecture of the entire computing system.

Working name:

Morphic Computing Fabric

The basic rule would be:

Keep semantics stable while making as much security-relevant implementation state as practical ephemeral.

A normal application could still say:

open file

or:

call service

or:

allocate memory

The developer sees a stable abstraction.

Underneath that abstraction, the implementation might continually change.

Code could morph

A function could have multiple equivalent implementations.

Function F

Epoch 81 → Representation 7A
Epoch 82 → Representation D4
Epoch 83 → Representation 19
Epoch 84 → Representation FF

Same input.

Same output.

Different machine-level realization.

Memory could morph

Addresses and pointer representations could continuously change.

logical object:
customer_record_14
Epoch A:
0x83A91...
Epoch B:
0x01F72...
Epoch C:
0xB448C...

The application doesn't care.

The attacker absolutely does.

This is already one of the areas MORPHEUS explored.

Capabilities could morph

Instead of giving software permanent credentials:

ADMIN_TOKEN=ABC123

the machine could use short-lived cryptographically authorized capabilities.

Capability 94822

resource: database
action: read
scope: customer/*
expires: 32 ms

Then:

Capability 94822

ceases to exist.

A new capability replaces it.

Stealing authorization becomes less valuable if authorization itself constantly expires.

Internal interfaces could morph

This is where the idea starts getting stranger.

Internal representations of:

RPC calls

IPC

service identifiers

serialization

handles

internal API mappings

could potentially become epoch-specific.

The application thinks:

GET CUSTOMER

The internal representation might be:

Epoch 217:
D4-881-B2

Then:

Epoch 218:
9F-442-AA

Same logical request.

Different internal representation.

Networking could morph

Not necessarily the public internet protocols themselves.

Something has to remain interoperable.

But inside a trusted system, temporary identities, channels, session keys and routing relationships could change constantly.

Instead of a static internal network:

Service A → Service B

you could have:

logical relationship
        ↓
ephemeral authenticated channel
        ↓
expires
        ↓
new authenticated channel

Again:

stable semantics, unstable implementation.

Then put AI inside it.

This is where I originally started.

Current AI security discussions tend to treat the AI as something sitting inside a normal computer:

AI
 │
 ▼
runtime
 │
 ▼
OS
 │
 ▼
computer

Then we try to put security around the AI.

But increasingly capable AI creates an unusual threat model.

An AI system may eventually become extremely good at:

reading source code

reverse engineering

probing systems

identifying vulnerabilities

understanding permissions

mapping infrastructure

generating exploits

adapting to defenses

So maybe it is backwards to design one special cage around AI.

Instead:

AI
Browser
Database
Web server
Application
Operating system
       │
       ▼
MORPHIC COMPUTING FABRIC

The AI gets exactly the same problem as any attacker.

It can understand the concept completely.

It can inspect whatever its permissions allow it to inspect.

It can reason about the architecture.

But the security architecture never relies on the AI being too stupid to understand it.

Understanding should not equal authority

This might be the most important part of the whole idea.

Security through incomprehensibility is probably a dead end against advanced AI.

Instead:

Let the AI understand the entire design.

Good cryptography already works this way.

Everyone can know how AES works.

Knowing AES doesn't give you the encryption key.

Likewise, an AI could understand:

This machine transforms every 10 ms.

This algorithm creates the transformations.

This is how capabilities work.

This is how memory gets remapped.

And still not know:

current secret entropy

future secret entropy

root signing keys

hardware secrets

next capability mapping

That is a much stronger security assumption.

Make hacking a race against entropy

This is where I think the concept gets really interesting.

Traditional exploitation looks roughly like:

discover
   ↓
learn
   ↓
prepare
   ↓
exploit

A morphic architecture inserts another process:

discover
   ↓
learn
   ↓
prepare
   ↓

STATE CHANGES

   ↓
knowledge invalid

Now the attacker has to beat the transformation clock.

Call it a race against entropy.

But I don't think speed alone is enough.

If the entire defense is:

"Hopefully nobody can reverse engineer it fast enough"

then eventually somebody probably will.

Especially once AI is doing the attacking.

So there should be two independent barriers.

Barrier 1: temporal complexity

The environment changes faster than reconnaissance can reliably become an exploit.

Barrier 2: cryptographic authority

Even if the attacker understands the current environment instantly, they still cannot manufacture:

valid signatures

future entropy

root capabilities

hardware-backed secrets

authorization

That combination seems substantially stronger.

What should NOT constantly change

There is an easy way to turn this into nonsense.

Continuously inventing new cryptographic algorithms would probably make the machine less secure, not more secure.

The cryptographic foundations should be boring.

Tested.

Analyzed.

Stable.

Things like:

  • Approved cryptographic primitives
  • Root verification rules
  • Security invariants
  • Semantic contracts
  • Authorization rules
  • Hardware root of trust

should change rarely and deliberately.

What changes constantly are the implementations built on top of those invariants.

  • keys
  • representations
  • locations
  • temporary identities
  • execution layouts
  • capabilities
  • internal mappings
  • runtime instances

The rule isn't:

Everything changes.

It's:

Anything an attacker benefits from learning should be considered for expiration.

This is not "unhackable"

I want to be careful about this part.

No serious security architecture should be described as literally unhackable.

A morphic machine would create new problems of its own.

For example:

The root of trust becomes incredibly important

If an attacker compromises whatever generates transformations or owns the root keys, the entire architecture could collapse.

Synchronization gets difficult

Multiple components need to agree on the current epoch without exposing enough information to defeat the defense.

Debugging gets harder

Developers need a stable way to observe a system whose internal representation intentionally refuses to stay stable.

Performance matters

Transformation consumes CPU time, memory bandwidth and energy.

MORPHEUS showed that some forms of churn can be surprisingly inexpensive.

That does not mean transforming an entire software stack would automatically be cheap.

Side channels still exist

Changing code representations doesn't magically eliminate timing, power, speculative execution, physical attacks or every other security class.

Stable interfaces remain targets

Any system that communicates with the outside world needs some stable behavior.

Attackers will naturally concentrate on whatever cannot morph.

Those aren't reasons not to explore the idea.

They're the research problems.

The first experiment could actually be pretty small

We obviously aren't going to design a new CPU tomorrow.

But we can test the abstraction.

Go back to the original Python idea.

Call it PythonEnc for now.

Take a subset of Python:

  • variables
  • arithmetic
  • if statements
  • loops
  • functions

Parse it into an abstract syntax tree.

Then compile that tree into our own intermediate representation.

For example:

x = a + b

might become:

Epoch 1:

R82 A
Q14 B
M71 R82 Q14
S29 X

Then regenerate the language:

Epoch 2:

F9 A
T33 B
C4 F9 T33
V88 X

Both programs perform exactly the same computation.

A tiny virtual machine executes them.

Then we verify:

Python output
      ==
PythonEnc output

for thousands or millions of generated programs.

Once that works, make the runtime change mappings while the program is running.

Then experiment with:

rotating keys

changing instruction mappings

equivalent instruction sequences

memory remapping

temporary capabilities

multiple execution layouts

At that point we're no longer testing encrypted Python.

We're testing the beginning of a Morphic Intermediate Representation.

And once you have an IR, Python doesn't matter anymore.

You could theoretically compile:

Python ──────┐
Rust ────────┤
C/C++ ───────┤
JavaScript ──┤
AI runtime ──┤
             ▼
      Morphic IR
             │
             ▼
      Morphic Runtime

Now the concept starts becoming an architecture instead of a language trick.

The bigger question

Computers have spent decades getting more standardized.

Standard CPUs.

Standard operating systems.

Standard runtimes.

Standard APIs.

Standard binaries.

Standard cloud infrastructure.

That standardization is incredibly useful.

It also means that once an attacker understands one target, much of that understanding transfers to millions of other targets.

Artificial diversity research has been pointing this out for decades.

AI may make that problem much more important.

Because the cost of understanding software is collapsing.

If intelligence becomes extremely cheap, fast and automated, maybe the scarce security resource becomes something else:

time.

Don't ask:

Can the attacker understand my computer?

Assume they can.

Ask:

Can they understand enough of the current computer, gain the required authority and execute an attack before that computer ceases to exist in that form?

That is a very different security model.

And that is the idea I want to explore.

Not an encrypted cage for AI.

Not a secret programming language.

A computer whose logical behavior remains stable while its exploitable physical and executable reality is continually disappearing underneath it.

A machine where knowledge expires.

A machine where understanding doesn't equal authority.

A machine designed around a simple assumption:

Eventually the attacker will understand everything they can see. So stop giving them a permanent thing to understand.

Prior work worth reading

This thought experiment builds on a lot of existing security research rather than starting from zero:

DARPA — SSITH launch and research goals, 2017.

Gallagher et al. — MORPHEUS: A Vulnerability-Tolerant Secure Architecture Based on Ensembles of Moving Target Defenses with Churn, ASPLOS 2019.

Williams-King et al. — Shuffler: Fast and Deployable Continuous Code Re-Randomization, OSDI 2016.

Kc, Keromytis and Prevelakis — Countering Code-Injection Attacks with Instruction-Set Randomization, CCS 2003.

Crane et al. — Thwarting Cache Side-Channel Attacks Through Dynamic Software Diversity, NDSS 2015.

The part I'm interested in is what happens when we take the common principle behind those systems and push it across the computing stack as a first-class architecture—especially in a world where increasingly capable AI can be both the software we're protecting and the thing doing the attacking.

That seems worth building a prototype for.

Record and method

Published October 4, 2026, from a research conversation and its AI-assisted article draft. Morphic Computing Fabric and PythonEnc are proposed research directions, not implemented or independently validated security products. Instruction names, memory addresses, capabilities, epoch numbers, and timings in the proposed architecture are illustrative. The related SCANGATE project explores a separate artifact-screening workflow; it does not implement Morphic Computing Fabric.