What if AI coding tools were only one layer of the problem?
AI coding assistants are getting incredibly good at generating code.
But building software with AI introduces a different challenge:
How do we manage, govern, validate, and operate AI-driven engineering workflows at scale?
That is the problem we are exploring with NAEOS — Nusantara AI Engineering Operating System.
NAEOS is an open-source experiment around an AI Engineering Operating System designed to connect:
→ AI agents
→ engineering workflows
→ repositories
→ tools and execution environments
→ policies and permissions
→ validation and observability
The core idea is simple:
An AI agent should not be trusted simply because its output looks correct.
When an agent can modify code, execute commands, access systems, or trigger deployments, we need an engineering control layer around it.
We are exploring what that layer could look like as an open-source system.
NAEOS is still early.
We are not claiming to have the final architecture.
Instead, we want to build this in the open — with developers, AI engineers, platform engineers, security engineers, and open-source contributors.
Some questions we are currently exploring:
• What should an AI Engineering OS actually control?
• Where should agent authorization live?
• How should policies be enforced outside the model?
• How do we make AI-generated changes auditable?
• What should become an open standard rather than another proprietary AI tool?
If you are working on AI agents, developer infrastructure, DevOps, platform engineering, or open-source tooling, I’d love to hear your perspective.
The repository is open for discussion, experimentation, and contribution.
NAEOS GitHub:
https://github.com/NAEOS-foundation/naeos
What do you think an open-source AI Engineering Operating System should provide?
One thing I’d make first-class is the handoff between components.
A lot of architectures secure the individual agent and the individual tool call, but then implicitly trust the transition between them.
If agent A hands a task to agent B, or a tool response becomes the next agent’s context, that transition is a new trust boundary.
I’d want the system to capture and validate at least:
who initiated the handoff
what capability is actually being requested
whether the payload still matches the expected contract
which inputs are untrusted
what downstream actions this handoff is allowed to enable
I’d also test those boundaries adversarially: extra fields, permission widening, replay, manipulated tool output, or a downstream agent interpreting data as instructions.
So for me the policy question isn’t only:
“Can agent X call tool Y?”
It’s also:
“Can this specific handoff grant these downstream capabilities in this state?”
I think that becomes increasingly important once agents start composing with other agents and protocols.
Are you planning to model agent-to-agent and tool-to-agent transitions explicitly in the control layer?
Yes — and this is something I think NAEOS should model explicitly rather than treating it as an implementation detail.
In the current NAEOS Reference Architecture, the policy layer sits above the execution/runtime layers, so I think the handoff itself should become a governed object — not just an internal message between components.
I’d model it roughly as:
Agent/Tool A → Handoff Contract → Policy Evaluation → Agent/Tool B
The handoff would carry things like:
This also fits the Policy Registry direction we’ve been exploring: a handoff shouldn't be able to implicitly widen the authority of the receiving agent just because the payload contains something that looks like an instruction.
For example:
Agent A: “Here is the tool output.”
should not automatically become:
Agent B: “Therefore I am authorized to execute X.”
The policy engine should evaluate whether that transition is actually permitted in the current state.
I also like the adversarial tests you mentioned. They map directly to what I'd want to test around the NAEOS runtime boundary:
payload manipulation → contract validation → capability check → policy re-evaluation → execution
And importantly, the audit trail should record the handoff itself, not only the eventual tool call. That gives us provenance across the chain:
who initiated → what was transferred → what was trusted → what capability was granted → what action followed
So yes, I think agent-to-agent and tool-to-agent transitions should be first-class governance boundaries in NAEOS.
The interesting next step is probably defining a minimal NAEOS Handoff Contract that can work across different agents and runtimes without depending on a specific vendor protocol.
I think the “handoff as a governed object” framing is the important part.
Especially the rule that authority must not widen implicitly just because the receiving component interprets something in the payload as an instruction.
A minimal protocol-neutral Handoff Contract could make that much easier to reason about — and also much easier to test.
I’d probably want the contract to be versioned and inspectable, with a clear distinction between:
what was requested
what was actually authorized
what came from untrusted input
what downstream capability was granted
Then you can test the transition itself rather than only the components around it.
That’s actually very close to what I’m exploring with HandoffProbe: adversarially testing whether those guarantees survive the handoff, including permission widening, replay, payload manipulation and data being reinterpreted as instructions.
One thing I’m curious about: would you see the NAEOS Handoff Contract as a portable declarative object — something like a protocol-neutral schema that an external validator could inspect — or more as an internal runtime abstraction?
I’d lean strongly toward making the NAEOS Handoff Contract a portable, declarative object, rather than only an internal runtime abstraction.
That seems more consistent with the vendor-neutral goal of NAEOS. The runtime should enforce it, but the contract itself should be inspectable and independently verifiable by an external validator, CI system, gateway, or even another agent.
Conceptually, I’d separate the contract into four things:
Requested — what the originating component is asking to happen.
Authorized — what the current policy actually permits.
Untrusted — which parts of the payload originate from external/tool/agent input and must not be treated as authority.
Granted — the exact downstream capabilities that the receiving component is allowed to exercise.
Then add versioning, policy reference, provenance, expiry/replay constraints, and an audit identifier.
Something like:
request → contract → external validation → policy decision → capability grant → executionThe important invariant would be:
That also makes something like HandoffProbe particularly interesting alongside NAEOS. HandoffProbe could attack the contract boundary — permission widening, replay, field injection, instruction reinterpretation — while NAEOS provides the declarative contract and enforcement semantics being tested.
So I wouldn't want Handoff Contract to be “NAEOS runtime magic.” I'd want it to be something you can serialize, inspect, diff, validate, version, and test independently of whichever agent or runtime happens to execute it.
That could become a useful interoperability primitive for the NAEOS ecosystem.
I think that separation is the right direction.
The next question I’d have is how strongly the contract should be bound to the state it was created for.
If it’s portable and independently inspectable, schema validation alone probably isn’t enough. You’d also want to prevent a valid-looking contract from being replayed, detached from its original payload, or having the granted capability changed after policy evaluation.
So I’d be tempted to bind at least:
the payload or canonical payload digest
the authorized capability set
the policy/version that produced the decision
the relevant identities/provenance
expiry / replay state
potentially with a signature or other verifiable attestation.
Then the invariant becomes stronger than “this object has the right fields”:
this exact authority grant was produced for this exact handoff state and has not been widened or substituted since.
That would also give HandoffProbe a very clean external test surface: mutate the payload, policy reference, grant, provenance or replay state and verify that the receiving side refuses the transition.
Would you want that integrity/authenticity layer to be part of the Handoff Contract itself, or would you keep signing/attestation as a separate transport/runtime concern?
Yes — I’d split those two concerns, but I would still make the integrity binding part of the Handoff Contract semantics.
The contract should define what must be bound together:
payload digest + authorized capabilities + policy/version + identities/provenance + expiry/replay state
That gives us a deterministic statement:
Signing or attestation can then be the mechanism used to prove that binding hasn't been altered. I wouldn't make the contract inherently dependent on one particular cryptographic or transport implementation.
So conceptually:
Handoff Contract
→ defines the authority/integrity claims
Policy Engine
→ produces the authorization decision
Attestation/Signature
→ proves the decision and bindings haven't been substituted
Runtime
→ verifies those claims before crossing the execution boundary
This also gives HandoffProbe a very clean adversarial surface.
For example, mutate any of these:
payload → digest mismatchcapability grant → authorization mismatchpolicy version → decision mismatchprovenance → identity mismatchexpiry/replay state → validity failureThe receiving side should reject the transition before the downstream capability is exercised.
I think that's stronger than making signing itself the security model. The cryptography proves integrity/authenticity; the contract defines what integrity and authenticity actually mean for the handoff.
And this fits the NAEOS architecture nicely: the contract can remain portable and protocol-neutral, while different runtimes can choose how they attest and enforce it.
The principle I'd want to preserve is:
That distinction makes a lot of sense to me: the contract defines the security semantics, the attestation proves the binding, and the runtime enforces it.
The next thing I’d probably make very explicit is canonicalization.
If the payload, capability set, policy reference and provenance can all be represented differently across runtimes, then two implementations need to agree on exactly what state is being attested.
Otherwise you could end up with something that is cryptographically authentic but semantically ambiguous.
I’d probably define a canonical handoff-state digest over something like:
normalized request / payload
exact capability grant
policy decision identifier + version
identities / provenance
expiry and replay material
Then the receiving side could verify in a strict order:
the attestation is authentic
the canonical state digest recomputes correctly
the policy decision is still valid for the current state
the capability grant has not widened
expiry / replay constraints still hold
only then allow the downstream effect
That gives a pretty strong invariant:
authenticate the decision, then revalidate the state — not just the signature.
It also creates a very deterministic adversarial test matrix for HandoffProbe because each binding can be mutated independently.
One thing I’d be curious about is whether you’d make the canonicalization rules part of the protocol-neutral Handoff Contract specification itself, or leave canonicalization to individual runtime profiles?