NAEOS Technical Build Log #002 Intent Is Not Authority

Yes — that’s a very useful production reference for the argument I’m making with NAEOS.

The important part to me isn't the specific implementation, but the architectural boundary: the model doesn't get to decide whether it can access the real capability.

A surrogate token inside the agent context, with a separate authority resolving the real secret and enforcing connector/egress rules, is a concrete example of:

Proposal → Policy → Runtime

with the sensitive capability kept outside the model's authority boundary.

That also strengthens the point about obedience. Even if the agent follows every instruction perfectly, the security property shouldn't depend on the agent continuing to behave correctly.

The interesting NAEOS question is how far that principle can generalize beyond secrets: repository writes, deployments, external APIs, infrastructure changes, and other side effects could all be treated as capabilities whose authority lives outside the model.

I'll definitely look at the Muse/Sentinel write-up as prior art. The per-user VM, surrogate-token, and network-edge pieces should be useful when thinking about where the NAEOS control boundary actually needs to sit.

And I like the distinction between what the model can see and what the runtime is actually authorized to do. That feels increasingly central to the architecture.

Exactly. I think that’s the demo NAEOS ultimately needs.

A green test result only tells us that something worked. It doesn't answer whether the agent was authorized to cause that change.

I’d want the demo to make the entire chain visible for one sensitive change:

1. Proposal — what the agent intended to do
2. Authorization — which policy granted the capability, with the relevant scope/version
3. Execution — what the runtime actually executed
4. Observation — what happened externally, with machine-verifiable evidence
5. Verification — whether the observed result matches the authorized intent

And importantly, the audit trail should make it possible to answer those questions without relying on the agent's own narrative.

That would also give us a good failure demo: change the policy or repository state after authorization, attempt the same action, and show the stale authorization being rejected.

For me, that's a much stronger proof than simply showing an agent successfully modifying production code. It demonstrates that success is not the authority — authorization and evidence are.

That's the kind of workflow I'd want to validate before arguing that NAEOS is ready for production access.

If I started NAEOS over, I’d probably spend less time designing the complete architecture upfront.

I had the instinct to define the governance model, layers, constitutions, policies, runtime, verification, and audit concepts early because the problem is inherently systems-oriented.

But I’ve learned that some boundaries only become obvious when you try to break the system.

For example, the distinction between tool interception and actual side effects became much clearer once I started thinking about shell escape paths. Similarly, decision, execution, and observation only really make sense when you have concrete evidence flowing through the system.

So I’d start with a much smaller control loop:

Propose → Authorize → Execute → Observe → Verify

Then deliberately try to break it through stale policy, shell execution, replay, modified state, missing evidence, and agent handoffs.

Only after those failure modes are understood would I expand the architecture around them.

In other words, I’d design less from the top down and let the failure modes tell me what the architecture actually needs.

And I’d still build it in public — the external challenges have probably saved me more time than another month of designing in isolation.