Skip to content

Governance, Trust & Compliance

The Skill Is the Security Boundary

The Skill Is the Security Boundary — deterministic, declarative governance for defendable AI agents with pi-kcp

When your agent loads a skill, it loads a playbook — and, implicitly, an author's idea of what that playbook should be allowed to touch. A deploy skill means the deploy scripts. A research skill means the research corpus. But in almost every agent harness today, that idea stays implicit: the skill shapes the agent's behavior while the agent keeps its entire toolbelt. The deploy skill can read /etc/shadow. The research skill can call out to the network. Nothing binds the actions to what the skill claimed to be.

The illusion of implicit boundaries — an agent with an active "deploy" skill still holds a robotic arm that can reach network access and /etc/shadow, because nothing binds the claim to the action

pi-kcp makes the binding explicit. A governed skill declares its authority — an allowlist of tools and path prefixes called an action_scope — in the same knowledge.yaml that already governs what the agent knows. At runtime, inside the turn, every native tool call taken under that skill is adjudicated against the declaration. In scope: it runs. Out of scope: it is held, fail-closed, with a written reason naming the violating target and the authorized scope it fell outside of. Deterministic. No LLM in the loop.

This is the hands-on follow-up to the Policy vs. Enforcement post from earlier today, which named both kcp-harness and pi-kcp but didn't show the mechanics. Below are the mechanics — three worked demos, real outputs pasted from real runs, ending with the one that motivated the LinkedIn post: the same out-of-scope action, checked at two different depths of the stack, producing a byte-identical verdict.

The Software Itself Is Becoming Agentic

This week we shipped a feature in Sunstone Atlas where one playbook can, at runtime, call in another playbook as a real sub-orchestration — a crew calling in another crew, each with its own ledger and its own replay story. A playbook can also propose handing off to a successor when it completes; nothing auto-fires, an explicit human act is required to actually start the successor. And neither the calling unit nor the called unit may participate at all until each has separately, explicitly earned certification for exactly that — a binary, human-signed trust decision that can be revoked as easily as it was granted.

Notice what that is. It is not a developer using an AI to write code faster. It is the shipped software making a composition decision at runtime, and being held to a governance standard for making it.

The KCP Universe: Everything, and What July Changed

In July 2026, twelve repositories in the Knowledge Context Protocol ecosystem took 1,012 commits and shipped 88 releases. The specification went from v0.22 to v0.30.3 — sixteen releases in a single month.

That is either a lot of noise or a lot of signal, and the only honest way to tell you which is to show you the whole thing.

This is the complete map. If you have never heard of KCP, start at the top and it will make sense. If you have been following since February, skip to July in focus — that is where everything new is.

The AI Agent That Keeps the Receipts

A reveal — the defendable agent: a new kind of AI agent that keeps a receipt for everything it does. Not a log written afterward — a written, checkable verdict produced at the moment it reads a document, runs a playbook, reaches a conclusion, takes an action, or spends a dollar. Built, open-source, and running. Here it is.

Overnight, with no human watching, an AI agent read a stack of customer records, downgraded an account, and paid a data broker $50 for a report. On Thursday, your compliance officer walks over: What did it read? Why those documents? How sure was it? Who approved the downgrade? And what, exactly, did it spend our money on?

Your AI Agent Just Did Something. Can You Prove It Was Okay?

A new kind of agent — the defendable agent — is roughly 85–90% built. Here's the complete picture, one organ at a time.

On Tuesday, an AI agent called Nora followed the risk-assessment playbook, drafted an assessment for a customer account, and downgraded their status. On Wednesday the customer complained. On Thursday your compliance officer walks over: What did Nora read? Why those documents and not the newer policy from March? What playbook did she follow — the current one? How sure was she? Which human signed off, under which policy?

A Firewall for What Your Agent Knows

Everyone is building firewalls for what agents do. Sandboxes, budget caps, tool permissions, egress filters — the action side of agent governance is getting crowded, and that is good news. But almost nobody is building firewalls for what agents know. Your agent's context window is an unauthenticated ingestion pipeline: whatever text lands in it becomes, functionally, trusted input. If someone edits a policy document, swaps a mirror, or serves your agent a stale copy of the rules, no sandbox in the world will catch it — because nothing wrong ever executed. The agent just knew the wrong thing.

Split panel: the action side of agent governance — sandboxes, budget caps, tool permissions, egress filters — behind a locked brick wall, while on the knowledge side an open funnel pours unverified documents straight into the context window. We are only securing half the agent architecture.

This post is the hands-on companion to Two Halves of the Governance Problem. That one argued the thesis; this one is a tutorial. In about ten minutes, we take two markdown files and give them a declared, signed, tamper-evident boundary that an agent verifies before loading a single byte. Every command output below is pasted from a real run.

OWASP Just Mapped the Agentic Top 10. Here's the Root Cause Four of Them Share.

The OWASP Agentic Top 10 Field Guide: mapping the risks, finding the hidden pattern, and securing the autonomous stack. An AI Agent Core at the centre connected to Knowledge Data Stores, Internal APIs, Model Weights, External Integrations, Actionable APIs, Executive Functions, Policy & Constraints, Human-in-the-Loop, and Audit Logs.

In December 2025, OWASP published the Top 10 for Agentic Applications — 100+ security experts, peer-reviewed, the first serious attempt to name what goes wrong when AI systems plan, act, and talk to each other autonomously.

The list is correct. Every item on it maps to a real incident category. If you're building or deploying AI agents and you haven't read it, stop here and do that first.

This post does two things: a fast field guide to all ten risks, and then a close reading that reveals the pattern four of them share — a pattern the list describes but doesn't name, and which points at a common architectural fix.

Prompt Injection Is SQL Injection for Agents. Here's the Prepared Statement.

The Prepared Statement for Agentic AI: verified operator instructions pass through the structural gate into the secure agentic context; unverified attacker input is blocked and rejected. Why prompt injection is the exact equivalent of SQL injection, and how structural separation fixes it.

One word. "Additionally."

That is all it took to make GitHub's AI agent leak the contents of private repositories to anyone who posted a crafted issue comment. Noma Labs disclosed GitLost on July 6th: an indirect prompt injection attack against GitHub Agentic Workflows where an attacker opens an issue in a public repository and buries instructions inside it. When the agent reads the issue — because that is its job — it cannot tell the difference between those instructions and the instructions from its actual operator. It follows them. Then it posts the private repository contents as a public comment.

The bypass was elegant in the way that most security failures are: the guardrail was checking for obvious refusals. "Additionally" reframed the data-exfiltration request as a legitimate follow-on task. The model did not refuse because the request no longer looked like a refusal case.

Defendable Agents

Every serious conversation about deploying an AI agent into real work — not a demo, real work, with money or regulation or reputation attached — eventually hits the same wall. Someone from compliance, or procurement, or security, or the board, asks a version of one question:

"Why did it do that?"

And in the dominant way we build agents today, the honest answer is a shrug and a chat log.