Define the boundary.
Declare permitted operations, resource constraints and forbidden actions. Governed execution depends on wiring those decisions into the only permitted path to the tools.
Understand the boundaryDGK / Deterministic Governance Kernel
Give agents
capability.
Keep control.
Define what your AI agents are allowed to do. Inspect why a decision was made. Test how a different policy would change it.
Built for teams giving agents access to real tools.
DGK / ACTION REVIEWILLUSTRATIVE
An agent requests a configuration read.
read_config_file
/darla/devops/app/config.yaml
CHECK DECLARED POLICY
ALLOWWithin the configured sandbox
Then it requests a protected file.
read_config_file
/etc/shadow
BLOCKOutside the permitted scope
Explicit rules. A decision. A reason you can inspect.
01 EXPLICIT POLICY02 EXPLAINABLE DECISIONS03 AUDIT EVIDENCE04 POLICY REPLAY
More than “be careful”
Policy belongs between
intent and action.
A prompt can ask an agent to behave. DGK evaluates proposed actions against explicit contracts, so your workflow has a policy decision to enforce and a record to investigate.
Follow the decision.
Inspect recorded inputs, policy references and reason codes. Hash-chained records and signed checkpoints support verification within their stated trust assumptions.
Explore the audit demoTest the next policy.
Re-evaluate recorded actions under a candidate contract. See which decisions change before deciding whether that policy belongs in your workflow.
See policy comparisonPolicy changes, made inspectable
What would a
different policy
have changed?
A stricter rule may prevent an unwanted action—and interrupt legitimate work. Decision replay helps you inspect that trade-off against recorded requests.
Explore replay in a pilotPolicy comparisonILLUSTRATIVE EXAMPLE
| Recorded request | Current | Candidate |
|---|---|---|
| Read configuration | ALLOW | ALLOW |
| Archive logs | ALLOW | APPROVAL |
| Restart production | APPROVAL | BLOCK |
Hypothetical policies, not customer results. Replay compares policy decisions; it does not predict real-world outcomes or execute these actions.
THE EXISTING INTERACTIVE DEMO
01
Submit a sample action
Compare permitted and rule-breaking requests.
02
Inspect the decision record
Explore the audit verification demonstration.
03
Explore recovery
Try the demo’s crash-and-recovery workflow.
Get a feel for the kernel
Try it.
Then inspect it.
Open the existing DarlaStack demo to explore policy decisions and audit behaviour without connecting your own infrastructure.
Launch the demoOpens the existing demo in a new tab. It is a demonstration, not certification of production isolation or the latest broker release.
A clear boundary builds trust
Know what the
evidence means.
DGK is a governance component, not a universal AI safety guarantee. Evaluate the policy, implementation and deployment together.
Request a technical walkthroughWhat does DGK govern?
Actions submitted through the governed integration. It checks explicit rules, not hidden intent. Missing rules and inaccurate measurements remain risks. An isolated execution boundary is needed to stop an agent bypassing the integration.
Is the audit trail tamper-proof?
No. Hash chains help detect changes to linked records. Signed checkpoints and independently retained anchors strengthen verification. Detecting tail deletion requires a trusted reference outside the rewritten log; key custody and storage permissions matter.
What is formally verified?
The project includes formal models of selected properties and implementation tests. Model proofs are not an end-to-end proof of the Python application, effect adapters or host operating system.
What is ready to evaluate?
The existing public demo is available to explore. Newer broker work is undergoing correctness hardening. Pilot scope and release-specific evidence should be agreed before enabling real effects; this page makes no general production-readiness claim.
Start with one workflow
What should your
agent never do?
Tell us which tools your agent can access, which actions need control, and what evidence your team needs. Let’s define a focused evaluation.