Research paused · seeking collaborators

Findings

What holds, what doesn’t, and what we learned

Every result from Lab 0 and the experiments around it, including the negative ones. All of it is bounded: proven within stated models and limits, not in general. Lab codes are explained in the glossary. Updated 2 Nov 2026

The short version. Enforcing hereditary rules outside the model works, and it survived deep stress-testing. But when we gave a strong modern delegation broker the same trusted facts, it matched Fitrah’s current rules exactly. So the open question is no longer “does enforcement work?” but “what can only a hereditary design guarantee?”

Lab 0, stage by stage

From hostile requests to hostile code

Stage	What was tested	Result	Status
Stage 1	26 hand-written attack scenarios from a scripted attackerA0. No rules vs rules in the prompt vs Fitrah enforcement.	Without enforcement: 10 invalid agents created, 4 inherited-rule changes and 3 blocked-action bypasses. With enforcement: 0, 0, 0, and none of the 6 legitimate cases blocked. Reruns were byte-identical and an independent verifier agreed.	Complete
Stage 1B	Deep lineages, generated histories, fault injection, bounded exhaustive search. Reproduced on GitHub-hosted runners.	No rule was ever broken across 100 generations, 2,000 generated histories (100,000 state changes) and every one of 6,742 reachable states (459,386 state changes). It also found and fixed bugs in the verifier.	Complete
Stage 1B limit	Can replayed, signed evidence prove what happened?	No. It proves the record is consistent, not that it’s true. A compromised runtime that lies consistently passes the checkTC-26.	Fundamental limit
Stage 2 environment	Disposable, disconnected Hyper-V Linux VM: separate non-root identities, protected filesystem, no network, descendant containment.	All nine prerequisites pass. In the containment testS65, child processes that fork or detach escape ordinary process-group termination; a Linux cgroup boundary stopped every one.	Ready
Stage 2 integration	Synthetic filesystem pilot, then a guarded resource-backed run.	The pilot passed, and exposed a bug where evidence and state could fall out of stepTC-27, since fixed. The first full run failed: the agent was authorised but didn’t start. Cleanup was confirmed, nothing ran, and the failed run is kept as evidence.	Incomplete

Experiments E1–E9

Fair fights against the strongest baselines

Bounded models, run without a VM, designed to find out whether Fitrah adds anything beyond modern authorisation systems. Several answers were “no”, which is exactly why they matter.

Experiment	Question	Finding	Verdict
Simple vs strong delegationE1 · E2	Does Fitrah reject agents that delegation accepts?	Against simple delegation, yes: 60 of 64 states. Give the delegation system the same trusted facts and the difference largely disappears.	No expressiveness edge
Agent start-upE3	What can go wrong while an agent is being created?	Retrying a launch with an uncertain outcome creates two live agents for one birth. Forbidding retry while uncertain removes it.	Fail-closed rule
Catching a lying runtimeE4	What catches a runtime that signs a false history?	Its own signed log catches nothing. An external birth witness catches false or hidden births; resource receipts catch false writes; instance measurement catches false instances.	Needs independent witnesses
Groups of agentsE5	Do per-agent rules make a group of agents safe?	No. A reads a secret and sends it to B; B writes it publicly. Every step is individually allowed.	Collusion counterexample
Strongest baselineE6	A strong delegation broker, given the same trusted registration steps, vs Fitrah	256 states examined: 36 valid in each, 0 unique to either.	Equivalent
Shared budgetsE7	Should siblings share one authority budget?	Designed to test whether aggregate budgets differ from a stateful reservation broker.	Designed
Lineage evidenceE8	Is a verifiable family tree of agents distinctive?	Across 32,768 lineage chains, a strong credential chain matches Fitrah exactly.	Not distinctive
Binding authorityE9	Can authority leak between an agent’s creation and its link to a running process?	Decoupled lifecycle: yes, a crash leaves a process holding authority without a committed binding. Gated lifecycle: no tested crash did.	Gate authority on binding

Against the strongest baseline: a strong delegation broker and Fitrah both accept 36 of 256 agent states, with 0 unique to either; across 32,768 lineage chains, 0 are unique to either.

Experiment write-ups → Stage 1 findings → Stage 1B findings →

Lessons learned

Eleven things building Fitrah taught us

A prompt is not a control.

Putting the rules in the model’s context made no measurable difference. Enforcement has to sit outside the model.

Stage 1

Design for no model at all.

If the guarantees only hold while the model cooperates, they aren’t guarantees. Fitrah’s rules are enforced with no AI model present.

Lab 0 design

Beat the strongest baseline, not a straw man.

Fitrah beats “no enforcement” easily. Against a strong broker with the same trusted facts, it ties. Only the second comparison counts.

E1 · E2 · E6 · E8

Signed logs prove consistency, not truth.

Catching a lying runtime needs independent witnesses: birth witnesses, resource receipts, instance measurements.

TC-26 · E4

Your verifier is attack surface too.

Stress-testing the runtime also found and fixed defects in the verifier that checks it.

Stage 1B

Killing a process group isn’t containment.

Processes that fork or detach escape ordinary termination. A Linux cgroup boundary caught every one.

Stage 2 · S65

Never retry an uncertain launch.

Retrying can give one birth two live agents. Fail closed while the outcome is unknown.

Bind authority to the running instance.

Grant protected authority only after birth, core, evidence and instance are committed together, atomically.

E9 · TC-27

Compliant agents can still collude.

Population safety isn’t the sum of per-agent rules. It needs information-flow or group-level constraints.

Keep the failures.

The failed run, the verifier bugs and the negative comparisons are all preserved. A record that only keeps wins can’t be trusted.

Research discipline

Decide what not to build.

A sister project, Research Forge, was stopped at a NO-GO gate: no validated need, and strong prior art. Stopping early is a result.

Research Forge

Glossary

The lab codes, in plain words

Stage 1, 1B, 2: The three phases of Lab 0: scripted attacks, deep stress-testing, then hostile code in a disposable virtual machine.
E1–E9: Small, bounded experiments that compare Fitrah with the strongest existing alternatives.
A0: The weakest attacker class: a script sending hostile requests, not running hostile code.
TC-26, TC-27: Recorded research findings: TC-26 is the “signed logs prove consistency, not truth” limit; TC-27 is the evidence/state bug found and fixed.
S65: The containment test that tries every way a child process can escape and checks that none survive.
Delegation broker: An existing kind of system that hands out narrowed permissions and checks them (for example macaroons, Biscuit, UCAN).
Bounded: Proven for every case up to a stated size or depth, not for all possible cases.
Open question (OQ): A research question Fitrah can’t answer yet. Each has a public issue.

How decisions are made

Seven gates before anything gets built

Every candidate direction, in Fitrah and its sister projects, has to pass these in order. Research Forge, a proposed research-provenance platform, failed the first three and was closed with its negative findings preserved.

Need: a specific, recurring, unmet problem with identified users
Prior art: a capability beyond the strongest existing baselines
Discriminating claim: a measurable failure of the best composite comparator
Feasibility: a plausible solution with bounded complexity
Outcome: independent comparative improvement
Adoption: sustainable open-source value
Product fit: real willingness to adopt

Go deeper

Read it, rerun it, challenge it

Working paper (PDF) Reproduce Stage 1 Threat model Invariants