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.
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."
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.
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.