DEV Community: Laziz Kironov

The five blind spots in AI governance nobody instruments for

Laziz Kironov — Thu, 24 Sep 2026 07:15:22 +0000

Most AI governance stops at the dashboard. But the gaps that actually bite in production are the ones between the layers — shadow AI, agent delegation, prompt-level leaks, expiry, and unprovable audit trails. A field guide

Most "AI governance" I've seen — and I've been building in this space — converges on the same shape: a dashboard, a log, a policy page. That's necessary. It's also where the thinking usually stops, and the gaps that actually cause incidents live between those pieces, not inside them.
This is a field guide to five blind spots I keep running into. None of them are exotic. They're the boring, structural gaps that don't show up until an agent does something nobody authorized and you're trying to reconstruct why. For each one I'll describe the problem, why the common approach misses it, and the shape of a fix. I'll mention what I've built where it's relevant, but the point here is the problem, not a product — most of these you can address with tools you already have.

Blind spot 1: Shadow AI is a network problem, not a policy problem

Every company has a policy about AI use. Almost none can tell you what AI is actually running. Someone spun up a local Ollama instance. A team wired an unsanctioned API into a cron job. A browser extension is quietly shipping prompts somewhere.
Why the common approach misses it: policies govern sanctioned usage — the tools you already know about. Shadow AI is by definition the stuff you don't. You can't write a policy for a model you can't see.
The shape of a fix: treat discovery as a detection problem, the way you'd treat rogue devices on a network. Endpoint signals (processes like ollama/vllm, listening ports, model-weight files on disk) plus passive network discovery surface what's actually running, independent of anyone declaring it. The key design rule: discovery must be read-only. Finding a service is not the same as connecting to it — nothing should auto-attach to a discovered endpoint without an explicit human decision, or your discovery tool becomes its own attack surface.

Blind spot 2: Prompt-level leaks happen before your logs ever see them

You log the request. Good. But by the time it's in your log, the secret has already left — the API key, the customer PII, the internal hostname — pasted into a prompt and shipped to a third-party provider.
Why the common approach misses it: observability is downstream. It records what happened; it doesn't intervene. Logging a leak is not preventing a leak.
The shape of a fix: put a masking chokepoint before the prompt leaves. Scrub secrets (cards, keys, IDs, PII) at the gateway, so the provider never receives raw sensitive input in the first place. A subtle upside: gateway-level masking protects you from the provider itself, not just from your own traces. App-level redaction only protects your logs; the prompt still leaves your building intact. (This one bites hardest with LLM providers — the data's gone the moment the request fires.)

Blind spot 3: Agent delegation has no subset guarantee

Single agents were easy to reason about. Now an orchestrator calls a researcher, which calls a writer, which calls a tool. Each hop hands some authority to the next — and in most setups, nothing structurally prevents a sub-agent from using a capability it was never granted.

Why the common approach misses it: prompt instructions ("you may only read, never write") get reasoned around. A capability boundary enforced in text is a suggestion. Under enough pressure — a retry, a clever completion, a tool that reframes "delete" as "cleanup" — it leaks.
The shape of a fix: enforce capability subsetting at every hop, structurally. A sub-agent can never hold more than the agent that spawned it. If the parent can't deploy, nothing it spawns can deploy, regardless of how the chain grows. This turns a prompt rule into an invariant. And log every rejected escalation separately with the exact over-requested capability — the rejections are the signal, because the attacker or bug doesn't know which check failed.

Blind spot 4: Delegations don't expire, so revocation is a fantasy

Say you do scope a delegation correctly. A parent hands a sub-agent a credential for a three-minute task. Then the sub-agent spawns an async job, or retries against a queue, and the work outlives the authorization. Now that credential is either expired mid-flight, or scoped so wide in duration that "revoking" it means manually hunting it down.

Why the common approach misses it: capability subsetting handles what, not for how long. Time is the dimension everyone forgets, and it behaves differently — capabilities only ever shrink down a chain, but time, once you introduce async work, doesn't stay neat.
The shape of a fix: monotonic TTL — a delegation can't outlive the one that authorized it, the temporal twin of the subset check. Enforce it at delegation time (a longer TTL is a violation) and again at action time (an action under an expired delegation is denied). The async case is genuinely hard and I don't think it's fully solved — the cleanest direction I've found is treating a queued job as a new delegation request at execution time rather than reusing the original grant, but that just relocates the question to "who signs the re-delegation."

Blind spot 5: A log you control is not proof

This is the one that reframes all the others. When an auditor — or a regulator under something like the EU AI Act — asks "who authorized this agent to do that?", you point at your audit trail. But your audit trail is a claim. If your server wrote the log, your server could have written anything. Monitoring tells you what a system says happened. It doesn't let anyone verify it independently.
Why the common approach misses it: the entire industry equates "observable" with "accountable." They're not the same. A dashboard is evidence to you. It is not evidence to someone who doesn't trust you.
The shape of a fix: make the authorization itself cryptographically verifiable. Sign each delegation (Ed25519 is a good fit — small keys, fast verification, deterministic). Store the exact signed payload so nothing has to be reconstructed. Then anyone can verify the signature against the signer's public key in their own browser, without trusting the server — the server holds only the public key, so it can verify but never forge. "Trust me, here's my log" becomes "here's the math, check it yourself." Put the delegation's expiry inside the signed payload too, so a lifetime can't be extended after the fact.

The through-line

Notice that four of the five aren't about any single system being wrong. They're about the seams — between sanctioned and shadow, between logging and intervening, between one agent and the next, between authorization and time. Governance tools tend to instrument the boxes and ignore the lines connecting them, which is exactly where autonomy leaks.
I've been building an open-source, self-hosted platform (Provenza) that tries to close these seams — the name is from provenance, because the thread running through all five is making the origin of an AI action provable rather than merely observed. It's early and I'm figuring plenty out, especially the async-expiry case above. But you don't need my project to take the ideas: discovery as detection, masking before the prompt leaves, subset-at-every-hop, monotonic TTL, and signed authorizations are all things you can build into what you already run.
If you're working on agent infrastructure, I'd genuinely like to hear which of these you've hit — and how you're handling the ones I clearly haven't fully solved. The comments on my last posts
thought me more than the posts ded.

Thanks to Pushpendra Agrawal and Reid Marlow — their comments on my earlier posts directly shaped blind spots #3 and #4 here. The rejected-escalation logging and the monotonic-TTL framing both came out of those conversations. This is the kind of feedback that turns a post into a feature.

GitHub: https://github.com/kironovlaziz-del/provenza
git clone: https://github.com/kironovlaziz-del/provenza.git

Why 'monitoring' isn't enough for AI agents — and how I made delegation cryptographically verifiable

Laziz Kironov — Tue, 22 Sep 2026 01:24:51 +0000

The problem nobody talks about with AI agents

We're rushing to give AI agents autonomy. An orchestrator agent calls a research agent, which calls a writer agent, which calls a tool. Each hop, one agent hands some of its authority to another.
Every "AI governance" tool I looked at solves this the same way: it logs everything. You get a dashboard, a timeline, an audit trail. Which sounds great — until you ask one uncomfortable question:
When an auditor asks "who authorized this agent to spend money / delete data / call that API?", is a log you control actually proof?
It isn't. A log is a claim. If the server writes the log, the server can write anything. Monitoring tells you what a system says happened. It doesn't let anyone prove it independently.
As agents get more autonomous — and as regulation like the EU AI Act starts demanding "verifiable accountability" — I think this gap becomes a real problem. So I tried to close it.

The idea: sign the delegation, not just log it

Instead of recording that Agent A delegated to Agent B, what if the delegation itself were cryptographically signed by A? Then:
Anyone can verify the signature against A's public key
The server holds only public keys — it can verify a delegation, but it can never forge one
An auditor can check the proof on their own machine, without trusting my server at all
That last point is the whole game. "Trust me, here's my log" becomes "here's the math, check it yourself."
I built this into an open-source platform (AI Control Tower), but the technique is general. Let me show the core of it.

Why Ed25519

For signing delegations you want:
Small keys and signatures (32-byte public keys, 64-byte signatures) — these get stored and passed around a lot
Fast verification — you may verify a whole chain of hops
Deterministic signatures — no per-signature randomness to get wrong
Available everywhere — including natively in the browser via WebCrypto
Ed25519 checks every box. It's modern, boring in the good way, and — crucially for the "verify in your browser" goal — supported by the WebCrypto API.

The tricky part: canonical bytes

Here's the bug that will silently break everything if you're not careful.
To verify a signature, the verifier must hash exactly the same bytes the signer signed. If your backend signs a JSON object and your frontend re-serializes it even slightly differently — different key order, extra whitespace, different number formatting — the bytes differ, and every verification fails, even though nothing was tampered with.
The fix is a canonical serialization both sides agree on. In Python (signing side):

import json

def canonical_bytes(payload: dict) -> bytes:
    # sort_keys + no whitespace = deterministic output
    return json.dumps(
        payload,
        sort_keys=True,
        separators=(",", ":"),
    ).encode("utf-8")

And the matching thing in JavaScript (verifying side) has to produce byte-for-byte the same output. JSON.stringify with manually sorted keys and no spaces gets you there for simple payloads — but test it against real data, because nested objects and unicode will bite you.
Lesson learned: write a test that signs on the backend and verifies with the exact frontend serializer, using awkward payloads (unicode, nested objects, numbers). That one test caught more bugs than anything else.

Signing (backend, Python)

Using the cryptography library (no exotic deps):

from cryptography.hazmat.primitives.asymmetric.ed25519 import (
    Ed25519PrivateKey, Ed25519PublicKey,
)

def generate_keypair():
    private_key = Ed25519PrivateKey.generate()
    public_key = private_key.public_key()
    return private_key, public_key

def sign_payload(private_key: Ed25519PrivateKey, payload: dict) -> bytes:
    return private_key.sign(canonical_bytes(payload))

When Agent A delegates, you build a payload describing the delegation (who, to whom, what capabilities, when), sign it with A's private key, and store the payload + signature + A's public key.

Verifying — in the browser, offline

This is the part that makes it verifiable rather than trust-me. Using WebCrypto in the browser:

async function verifyDelegation(publicKeyRaw, signature, canonicalPayloadBytes) {
  // import the raw 32-byte Ed25519 public key
  const key = await crypto.subtle.importKey(
    "raw",
    publicKeyRaw,
    { name: "Ed25519" },
    false,
    ["verify"],
  );

  return crypto.subtle.verify(
    { name: "Ed25519" },
    key,
    signature,
    canonicalPayloadBytes,
  );
}

The browser fetches the delegation's payload, signature, and the signer's public key, rebuilds the canonical bytes, and verifies — locally. The server never gets a chance to lie, because the proof is checked on the client. If the math checks out, you see a green "verified" badge; if anything was altered by a single byte, it fails.
(Note: browser Ed25519 support via WebCrypto is now widespread, but if you need to support older browsers, keep a graceful fallback that verifies server-side and clearly labels it as such — don't pretend a server-side check is the same guarantee.)

The other half: capabilities can only shrink

Verifiable signatures answer "did A really authorize this?". But there's a second rule that matters for agent safety:
An agent can never delegate more authority than it holds.
If A can call read and search, it must not be able to hand B write or delete. So every delegation runs a subset check: the delegated capabilities must be a subset of the delegator's own effective capabilities. If B tries to escalate, the delegation is rejected and an incident is raised. Combine that with the signatures, and you get a chain where every hop is both authorized (subset) and provable (signed).

Why this matters more every month

Single-agent systems were easy to reason about. Multi-agent systems — where agents spawn and delegate to other agents — are not. As they spread into companies, "show me the log" stops being good enough. People will start asking "prove it." Verifiable delegation is one way to have an answer.

Try it / steal the idea

The full implementation — signing service, capability validator, a live delegation graph where you click any edge and verify the signature in your browser — is open-source (Apache-2.0), self-hosted, and runs with one Docker command:

git clone https://github.com/kironovlaziz-del/provenza.git

GitHub: https://github.com/kironovlaziz-del/provenza
I'm a solo developer and this is an early, honest MVP — I'd genuinely love feedback, especially on the canonicalization approach and the capability model. If you're working on agent infrastructure, I'd like to hear how you're thinking about the accountability problem.
Have you hit the "monitoring isn't proof" wall with agents yet? How are you handling it? Let me know in the comments.