Before Your AI Agent Acts: An Executive Brief on Governance

---

An AI agent can give an excellent answer and still do the wrong thing. It can summarize the right document and post it to the wrong channel. It can complete a task and quietly spend more than anyone approved. It can write useful code that runs with far more access than the task needed.

None of those are answer-quality problems. They are governance problems, and they are the ones that reach your desk.

01 Seven questions you can ask without a technical background

Every action an agent takes on your company's behalf should have a clear answer to each of these:

1. Who is acting? A named, authenticated identity — a person, a linked account, or a specific automation — behind every action. "The agent did it" is never the whole answer.
2. On whose authority? Someone consented to this: a signed-in user, an explicit grant to an automation, an approved connection to a company account. Authority is borrowed, visibly, from a person who had it. A file reference or account identifier is only a locator; possessing the string is not consent.
3. What may happen? The agent chooses from a defined set of operations — the ones your team approved — with each request checked against the current service catalog and selected account, one at a time.
4. Where may it happen? In KDCube's reference split-isolation profile, work the agent writes itself runs in a separate, networkless executor with no platform or provider credentials and only narrowly mounted files.
5. How much may it consume? Every paid step that crosses the runtime's accounting boundary is checked against a budget before it runs and charged to the right person after. Overspend is refused up front, never discovered on an invoice.
6. What state may it change? Actions that change something real — a sent email, a filed task — use ordered, owner-fenced, idempotency-aware paths, so a retry can be recognized instead of blindly sending the email twice.
7. What evidence remains? Participating subsystems leave structured operational evidence: who acted, on whose authority, what was approved, what it cost, and what was produced. Retention and integrity policy determine whether that evidence becomes a durable audit record.

02 "Written down" versus "enforced"

Most organizations already have the policy document. The difference between a policy and a control is location: a policy lives in a repository; a control lives at the exact place where the action happens — and it refuses.

A policy becomes real when an action is declined on its behalf. The user asks for work their plan does not cover: the runtime checks the plan before a paid call on that accounting path runs, and the request stops there — no money has moved yet. An automation presents an expired credential: the check sits at the service's door and runs on every managed call — this call ends there. In the reference split profile, an agent's generated code asks for a file outside its narrow mounts: the file is not physically reachable from the executor — silence, by construction.

Sometimes the refusal is a human's — an approval step the execution system waits on. The point is where the "no" happens: at the action, not in a document.

That is the standard to hold any system to — including ours: for each of the seven questions, where is the answer enforced, and what happens at that place when the answer is no?

03 What this means when something goes wrong

Things will occasionally go wrong; governance decides what that costs you. In a governed system, an incident can be a bounded, explainable event: this actor, on this authority, took this approved action, at this cost, and here is the operational evidence. The actual blast radius follows the configured account, resource, budget, workspace, and deployment boundaries; revocation takes effect through the relevant runtime and provider path. The record also keeps the accepted request when the turn ends in an error, so the failure cannot erase what the user asked or make later turns disappear from history.

That is also what your auditors, your security team, and your board are really asking for. They rarely need the mechanism. They need the seven answers, with evidence.

04 Three questions for any vendor

• Which boundary does each advertised control actually enforce? Content filtering, action approval, and confined execution are different protections; one is not a substitute for another.
• Do identity and authority survive handoffs? The moment work crosses from chat to a tool, to a background job, to an outside service — does the system still know who is acting and on whose authority?
• What do you hold if you leave? Where do the records, the credentials, and the data live — and whose infrastructure are they on?

KDCube's answer to the third question is structural: it is self-hosted and open source. The runtime, its operational records, and platform-managed credential records live on infrastructure you choose, under your retention rules. Model providers and connected services remain explicit egress destinations selected and configured by the operator.

· Read the full story

This brief is the executive layer of a deeper analysis — the vendor landscape, the control layers, and the runtime mechanics behind each of the seven questions: