AI governance that runs inside the data platform.
Most AI governance governs documents. This governs what an agent does, at the moment it does it, using the same permission model as everything else that touches your data.
DataByte governs AI agents at runtime instead of on paper. Each agent is bound to a scope when it is built, answers inside the permission model of the person asking, runs on models hosted on your own infrastructure, and writes what it read, decided and changed into the same cryptographically chained audit trail as every other action on the platform. There is no separate agent log, and no service account standing between the agent and the policy.
A policy an agent cannot read is not a control.
Most AI governance work produces artefacts: a model card, a risk register, an approval chain that ends in a signed document. All useful, and none of it reaches the moment that matters, which is an agent in production touching something it should have left alone.
The gap is structural. In most products the agent sits outside the data platform and holds its own credentials and its own copy of the schema, so the platform cannot evaluate what the agent is about to do. It can only record that it happened, afterwards, in a log of its own.
Who authorised it, all the way down.
A service account makes the first question unanswerable: the trail stops at the account, and the person behind it is a guess. The delegation chain is recorded in full, and four fields describe the action itself.
Four properties of the runtime, and none of them is a promise.
Each one is enforced by the platform rather than asserted in a document, which is the difference between a control and an intention.
Scope is fixed when the agent is built
An agent is bound to the part of the platform it serves at the moment it is created. Editing its prompt changes what it says. It cannot change what it is allowed to reach.
It answers inside the permissions of the person asking
Not a service account with its own reach. Someone who cannot see a column in a report cannot get that column out of an agent either, and the same policy decides both.
Agent actions land in the platform audit trail
The same cryptographically chained trail as every other action, so there is no separate agent log to reconcile and no gap between the two where an incident can hide.
The models run on your own infrastructure
Self-hosted, alongside the rest of the platform. An air-gapped deployment stays air-gapped on the day you add agents to it, which is the test most AI governance stories fail.
Governance that survives the second month.
Most AI governance is designed for the launch review. These are the parts that matter once the agents have been running for a while and somebody asks what changed.
Per-agent telemetry
Invocations, latency, failure modes and cost, by agent and by version, so an agent that quietly degraded is visible before somebody complains about an answer.
Prompt changes are releases
A prompt is versioned and promoted like any other change, so the question "what was this agent doing in March" has an answer.
Continuous control evaluation
The same 70 executable controls across 16 domains that evaluate the rest of the platform also evaluate the agent layer. Nothing sits outside the posture.
The wider governance story, covering lineage, the catalogue and audit evidence across the whole platform, is on the Governance Fabric page. This one stays on agents.
Six governance questions, answered plainly on the FAQ: what is recorded for an agent action, whether a prompt can widen access, and how it maps to SOC 2 evidence.
Bring the hardest question you have.
We will show you the audit record for a real agent action, end to end, across all 41 copilots.