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 sits after the decision: proof the rules fired. I ran three documented external test passes on a similar runtime (FreshCtx, ADK-based, fail-closed on stale or unverifiable context; record: https://github.com/Hyperwise-LLC/freshctx/blob/main/docs/INDEPENDENT_RESEARCH_BRIEF_R3.md). Two patterns held every pass. A vendor own suite does not survive adversarial scenarios written by someone outside the room. And fail-closed only means something when the receipt shows the refusal happened, not when the docs claim it. Your Governance Lab is the right instinct. If it accepts runs from outside the team, publish receipts with the scenario set so buyers can replay it against their own policy. That is the layer between should act and provably acted right.
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.
Oh, this looks really nice, but just tell me something. How do you know where your tool is really useful and where is not? Do you recommend to go ahead with this implementationf for evbery kind of project or just production implementations? I think this works just for a couple of projects where you need to take care where the AI touches like a DB or a third service but let me know if I'm wrong.
You’re mostly right. I wouldn’t recommend NEES for every AI project.
If the AI only generates text and has no meaningful side effects, a full governance runtime may be unnecessary overhead.
NEES becomes much more useful when an agent can touch databases, call third-party services, modify accounts, trigger workflows, spend money, access sensitive resources, or otherwise take consequential actions.
So I see the strongest fit in production or production-like agent systems where execution, authority, risk and traceability actually matter.
For simple prototypes, it may be overkill. For action-taking agents, that’s where the value becomes much clearer.
Ok, that sounds really nice. I just have a recomendation for your product. Your web page shows a lot of technical concepts and all is built with the idea everyone know what is it a NEES, but I suposse most part of your possible clients could be vibecoders (non technical people; no offense) that does not understand the most part of the time what the IA is doing and with more reason in production enviroments. A professional developer could take all kind of strategies to avoid this with access roles, blocking tools, etc. but I think this could be really useful for those non technical people and they do not understand what is a NEES and all that technical words. I think it's a better idea try to build the web page with the idea of a person like that is looking for a product like yours but with a description and instructions easy to understand. It's just an opinion. Really nice product, I will ask for access request and try it :)
That’s very useful feedback, thank you.
You’re right — the current site leans heavily toward technical/developer language, while the value should also be understandable to founders and non-technical builders who are deploying AI into real workflows.
We should probably explain NEES more simply around the outcome: what the AI is allowed to do, when it should stop and ask, and how you can see why a decision was made.
I’ll definitely take this into the next website refinement. And thanks for offering to try it — I’d really value your feedback after using the Governance Lab / developer access.
The 'referencing a resource is not permission to operate on it' distinction is where most agent setups quietly break. I run agents that touch browser sessions and accounts, and right now the only guardrail is whatever I remembered to hardcode into the prompt. One thing I'm curious about: when NEES returns CLARIFY mid-task, does the agent get the question back to relay to the user, or is that on the caller to wire up? That handoff is always where my glue code piles up.
Yes — in RC2, CLARIFY is a first-class runtime outcome, not just a log flag. NEES returns a structured clarification response and prevents the action from executing until that ambiguity is resolved.
The caller/integration layer is still responsible for presenting that clarification back to the user, but the governance contract is explicit, so you don’t have to infer from free-form model text whether execution should pause.
In our Naina Persona integration, for example, CLARIFY → NO ACTION → response to user is handled as a dedicated path rather than custom prompt glue.
That handoff is exactly one of the areas we want to keep making easier for agent developers.
Building an analytics MCP with read-only defaults taught me the same lesson: referencing a resource should never auto-grant permission to operate on it. We made write access a separate explicit grant and it changed how users trusted the agent. ALLOW/CLARIFY/REFUSE beats binary allow/deny — most tools force users into all-or-nothing.
Exactly. That separation between resource reference and permission to operate is one of the core ideas in NEES.
We also found that binary allow/deny is too crude for agent systems, which is why NEES uses outcomes like ALLOW, CLARIFY, ESCALATE, and REFUSE.
In many cases, the right answer isn’t “yes” or “no” — it’s “not yet, ask for the missing authority/context first.”
Your read-only-by-default MCP example is a very good illustration of why that matters.
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.
Thanks, Anna. One useful control for that paired scenario: change a policy the decision does not depend on. I'd expect the original trace to stay intact in both cases, but only the relevant change to flag the decision for reassessment. That would distinguish dependency-aware requalification from simply rerunning everything whenever a version changes.
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.