Over the past few weeks, I’ve been writing about a problem that keeps showing up as AI agents become more capable:
How do you govern what an AI system is actually allowed to do before execution happens?
Prompting helps with behavior.
Application logic helps with permissions.
Monitoring helps after something has already happened.
But once an AI system can call tools, modify data, trigger workflows, or act on behalf of a user, I think governance needs to become a runtime concern.
That is what I’ve been building with NEES Core V2.
This week, I published the first public developer preview of the NEES Python SDK.
And one design decision is worth explaining upfront:
The SDK is intentionally much smaller than the Core behind it.
What the SDK exposes today
The current release is:
nees-core-sdk 0.1.1
Install it from PyPI:
pip install nees-core-sdk
Then create a client:
from nees import NEESClient
client = NEESClient()
The SDK reads your API key from:
NEES_API_KEY
A basic request looks like this:
result = client.chat(
"Explain runtime governance in simple terms."
)
print(result.reply)
The current SDK exposes one documented capability:
chat:invoke
It also returns selected public governance information:
print(result.governance.decision)
print(result.governance.status)
print(result.governance.reason)
Applications can also correlate requests through fields such as:
result.session_id
result.request_id
result.trace_id
The trace ID is optional.
That is the supported public contract today.
Why expose only this much?
Because NEES Core itself is already significantly broader than this first SDK release.
- The runtime includes supported mechanisms around:
- request and intent qualification
- authority and delegated authority
- resource and operation scope
- human approval and resume
- state-aware requalification
- execution qualification
- decision and evidence lineage
- sequence and business limits
- cost governance and model routing
- containment
- enterprise governance
- bounded governed action execution
But exposing an internal capability and exposing a stable developer contract are two different things.
I don’t want developers depending on internal engine behavior that may change as the platform evolves.
So instead of turning every internal capability into a public method immediately, the SDK starts with a deliberately small interface.
The principle is simple:
stable public contract outside, evolving governance engine inside.
The SDK is not NEES Core
This distinction matters.
The Python SDK is a client.
NEES Core runs behind the supported NEES service boundary.
Installing the SDK does not mean you are installing the Core engine locally, and the SDK does not expose the proprietary governance implementation.
The current SDK also does not yet expose the full action-governance surface.
For example, you should not assume that SDK v0.1 gives direct access to:
- consequential action submission
- approval and resume workflows
- external execution
- action evidence APIs
- administration
- policy management
- delegation management
- containment controls
Some of these capabilities exist in the Core today.
They are simply not part of the public Python SDK contract yet.
Future SDK releases can expose more of the supported governance surface as those interfaces become stable enough for external developers to depend on.
So how can developers see more than chat?
This is where the Governance Lab comes in.
The SDK answers:
“How do I integrate with NEES from Python?”
The Governance Lab answers:
“What does NEES governance actually look like when it runs?”
The public Governance Lab demonstrates a broader selection of NEES behavior than the current SDK exposes.
It lets visitors interact with governed flows and inspect normalized results without exposing the Core implementation.
That includes reasoning-only interactions as well as a bounded governed reference-action path.
On the governed action path, visitors can see things such as:
- governance decision
- action state
- execution result
- linked evidence
- action and trace correlation
This matters because it is easy to describe governance in abstract terms.
It is more useful to show a request moving through a real governed lifecycle.
The current production reference-action path has been validated through NEES Core and linked evidence can be retrieved for the same governed action.
That moves the conversation from:
“the policy engine returned ALLOW”
toward:
“this specific action was governed, executed through a participating path, and produced linked evidence.”
What NEES is not claiming
There is an important boundary here.
NEES does not claim universal control over:
- arbitrary Python code
- all operating-system activity
- every network request
- every external service
- every possible agent tool
Execution governance is strongest when an action participates in a registered and governed path.
That is intentional.
A governance runtime should be very precise about what it actually controls.
I would rather describe a bounded enforcement model accurately than claim that a software layer magically governs everything an agent can ever touch.
Why this becomes more than a developer problem
One thing I’ve learned from conversations around the project is that the technical enforcement layer is only part of the problem.
In a real organization, someone eventually has to answer questions like:
- Who owns the policy?
- Who defines the agent’s authority?
- Who can approve a sensitive action?
- What happens when policy changes after an action was previously allowed?
- What evidence is available when an action is refused or executed?
- What does a security, risk, or audit team actually see?
That creates two different product requirements.
The developer needs a clean integration surface.
The organization needs boundaries, accountability, evidence, and a defensible explanation of why an action was allowed or denied.
That is why I’m treating the SDK and the Governance Lab as two different parts of the developer preview.
One is the integration entry point.
The other is the public proof surface.
Try the developer preview
Developer documentation and examples:
https://github.com/NEES-Anna/nees-python-sdk-developer-preview
Governance Lab:
Developer access:
https://nees.cloud/request-access
API access is currently controlled while I learn from early integrations.
I’m particularly interested in developers working on:
tool-using AI agents
workflow automation
enterprise copilots
assistants that modify business data
applications where AI acts on behalf of users
And I’d genuinely like feedback on one question:
If you were integrating a governance layer into an existing AI agent today, what would you want exposed next after governed chat?
- Action submission?
- Approval and resume?
- Evidence lookup?
- Authority and scope?
- Something else?
That feedback will help determine which parts of the broader Core become stable public SDK contracts next.
Top comments (0)