I’m building a runtime governance layer for AI agents — not another prompt guardrail
AI agents are getting better at acting.
But that creates a different problem:
Just because an AI can do something, should it be allowed to?
That is what I’m building NEES Core Engine V2 around.
NEES is a runtime governance engine for AI applications and agents.
The basic flow is:
Request → Govern → Execute → Trace
Instead of relying only on a system prompt, NEES evaluates the request before execution and can return decisions like:
ALLOW · CLARIFY · ESCALATE · REFUSE
The current Developer Preview RC2 includes work around:
semantic request understanding
authority and resource checks
cost governance
context budgeting
model routing
governed caching
runtime traceability
One concept I care about a lot is this:
Referencing a resource should not automatically mean permission to operate on it.
That distinction becomes important once agents start touching accounts, files, workflows, tools, or real-world systems.
I also built a public Governance Lab where people can compare:
Without NEES vs With NEES
using synthetic scenarios like:
ambiguous authority
policy override attempts
prompt injection
escalation paths
session boundaries
replay consistency
custom tests
The lab does not perform real account actions and is not meant to be a universal compliance or security certification.
The goal is simpler:
make governance behavior visible instead of hiding it behind claims.
Current stage: Developer Preview RC2
GitHub:
https://github.com/NEES-Anna/nees-core-developer-preview
Live Governance Lab:
https://nees.cloud
I’d especially like feedback from people building agents, AI workflows, tool-using assistants, or governance/safety infrastructure.
What do you think is the biggest missing layer between “AI can act” and “AI should act”?
The missing layer, for me: a rule about which decisions stay human. Not per-request permission.
I run an agent that drafts posts, keeps the books and writes the daily report.
Two things stay manual. Anything that moves money. The final wording of anything published under my name.
Everything else runs unattended.
What I would want from a governance layer: declare that boundary once, then show me every time the agent came near it.
That’s actually quite close to what NEES is designed to support.
Today, NEES already has the pieces around authority, execution control, escalation, policy enforcement, and traceability that can keep certain actions from running unattended. So something like “money movement must stay human” fits naturally into the governance model.
The part we’d still want to make more explicit is the declare-once human-only boundary you described — where an operator marks an action class as non-delegable and NEES consistently surfaces every time an agent approaches or attempts it.
So the underlying governance capability is there; your suggestion is a strong way to formalize and expose it as a clearer operator-facing control.
The distinction I'd watch is whether NEES becomes a measurement system or an enforcement system. Traceability is useful, but only if the trace itself contains enough precision to answer the hard question: did we make this governance call against the right context? Most governance systems log the decision (yes/no), but not the hidden assumption that invalidated it. An audit finds "we allowed X, context later changed, bad outcome." The real signal is whether the trace captures enough context-specificity to say which assumptions got invalidated and whether you should have re-qualified. That's the difference between "we logged it happened" and "we can reproduce why it was decided at that moment."
That distinction is important, and NEES is designed as more than a measurement layer.
It already sits in the runtime path and can enforce outcomes such as ALLOW, CLARIFY, ESCALATE, or REFUSE, with action/no-action control rather than only logging what happened afterward.
On the trace side, NEES also records structured governance evidence such as the interpreted intent, resource/action classification, authority requirements, policy lineage, decision metadata, and execution path.
Where I agree with you is the next level: the trace should make it possible to identify which decision assumptions were valid at that moment, which later changed, and whether that change should trigger requalification.
NEES already has the runtime and traceability foundation for that, but generalized assumption-invalidation and requalification across changing data/policy/model/context is something we’re making more explicit rather than claiming it is fully solved today.
The missing layer is not only authorization, but binding each decision to the exact state it was made against. An agent can be allowed to act and still be wrong because the data, policy, or context changed after qualification. I’d want the trace to answer: which data and policy version did this decision use, what changed, and does that change trigger requalification? Without that, ‘governed at runtime’ is difficult to reproduce later.
That’s a good point — reproducibility depends on binding the decision to the exact runtime state and policy/context used at that moment.
We have a public Governance Lab linked in the post where you can inspect and test the current runtime behavior directly: https://nees.cloud
Would be interested in your feedback after trying it, especially around traceability and requalification behavior.
I’ll take a look. The part I’ll pay particular attention to is the requalification trigger: how does NEES determine that a change in data, policy, model, or context invalidates a previous qualification? Is that explicitly defined by the operator, inferred by the system, or handled differently depending on the type of change?
Good question. In the current RC2, NEES evaluates the request against the runtime state and governance context available at decision time rather than treating a previous qualification as permanently valid.
A generalized requalification trigger across policy, data, model, and context changes is something we’re still defining more explicitly — including which changes should be operator-defined versus runtime-detected.
I’d be interested in your feedback after you inspect the Governance Lab, especially on that boundary.
I ran one Replay consistency scenario and saw the escalation decision and trace ID. For requalification, I'd start with operator-declared dependencies and have the runtime flag changes to those versions. Then show which earlier decisions need reassessment. A paired example with one policy change would make that boundary much easier to inspect.
Thanks for actually testing the Governance Lab — this is exactly the kind of feedback we’re looking for.
I like the operator-declared dependency approach as a first step: bind a decision to specific policy/data/context versions, detect changes to those dependencies, and explicitly surface which previous decisions may require requalification.
A paired Governance Lab scenario showing the same request before and after a policy change would also make that behavior much easier to inspect.
I’m noting this for the next refinement cycle.
The technical case is right, the harder problem is who signs the check. Governance gets bought by security and compliance, not by the developer wiring up the agent, and those are two different motions with two different cycle lengths. I would lead with the traceability piece rather than the category, because enterprises do not buy governance, they buy the ability to answer "show me every action this agent took and who approved it" the day an auditor asks.
That’s a strong point. I agree the buyer and the implementer are often different people.
Traceability may indeed be the more practical entry point: not “buy governance,” but “show me what the agent did, why it was allowed, and what decision path led there.”
That’s one of the areas we’re building heavily into NEES, and I think you’re right that it may resonate faster with security/compliance teams than the broader category language.
The distinction between “can act” and “should act” is compelling, but the commercial question seems to be where this becomes painful enough to install infrastructure. Have you seen teams encounter a real runtime decision they couldn’t safely handle with their existing permissions and policy layers?
Existing permissions answer who can access what.
NEES focuses on whether that capability should be exercised for this specific request, in this context, right now.
That runtime decision layer is the gap we’re testing with RC2 and the Governance Lab.
That clarifies the distinction. What’s the strongest real-world example you’ve seen so far where an agent was technically permitted to act, but the context made that action unsafe or inappropriate?
We’ve already completed and verified the current testing cycle for NEES Core Engine V2.
At this stage, we’re specifically looking for feedback from developers who are actually building or integrating AI agents/workflows in real environments.
So our next focus is real developer usage, integration feedback, and deployment evidence rather than another review cycle.
Thanks, that makes sense. I’ve also sent you an email with a more detailed proposal around the hands-on RC2 product work we discussed. Have a look when you get a chance.