Earlier this week I read Daniel Nwaneri's piece on induced authorization — the observation that agents don't just do unauthorized things, they cause humans to do unauthorized things. His central example: an agent gives advice, an engineer widens a permission based on that advice, the agent's action log shows nothing unusual. The exposure is real. The log is clean.
He named this the induced-edge problem, and the framing is sharp enough to deserve a concrete answer.
Here's the answer CORE gives — and the gap it still doesn't close. And why that gap is not an oversight, but a frontier.
Two Logs, Not One
Most agent governance architectures assume one audit object: the action log. What did the agent do?
The induced-edge problem reveals that this is the wrong unit. There are actually two logs:
Log 1 — The action log. What the agent executed directly. This exists. For CORE, it's the blackboard: every worker posts findings, proposals, and outcomes to a PostgreSQL append-only record. Nothing is retracted. Nothing is amended. The audit trail is a fact of the architecture, not a feature someone remembered to add.
Log 2 — The consequence log. What happened in the world as a result of the agent's output. This doesn't fully exist yet. Not in CORE. Not in most systems.
The distinction matters because these two logs decay differently. Direct edges — things the agent did itself — are trackable and can be pruned when unused. Induced edges — state changes that the agent's output caused a human to make — don't decay on the same clock. A widened permission persists independently of whether the agent keeps referencing it. It's effectively permanent until someone explicitly reconciles it.
What CORE Gets Right
Before the gap, what the design actually solves.
CORE's blackboard is append-only by architecture. Workers post findings; they cannot revise or retract them. This matters because of a question Daniel raised that I think is underappreciated: what keeps the audit history honest while a materiality classifier is being trained on it?
His concern: if the classifier's training data can be gamed — even slowly, even unintentionally — you don't just end up with a gameable threshold. You end up with a corrupted evidence base. The reconciliation record loses its value at the same rate the classifier loses its integrity.
CORE's append-only constraint answers this structurally. The blackboard accumulates an honest history not because workers are trustworthy, but because the architecture makes revision impossible.
The proposal lifecycle adds another layer. When a proposal requires human approval, CORE records the approver identity and timestamp against the proposal record. approved_by, approved_at — persisted to the database, queryable, part of the chain. This isn't incidental. A dangerous proposal that executes without a recorded approver fails validation. The authorization chain is a first-class fact.
This is what Daniel meant when he argued the reconciliation record is the primary value — more important than whatever threshold sits on top of it. CORE was built around this conviction. The Final Invariant — CORE must never produce software it cannot defend — is not about catching violations. It's about maintaining a record from which any decision can be reconstructed and justified. The defense is the record.
Where The Gap Actually Lives
CORE logs that I approved a proposal, and when. What it doesn't log is what I did as a consequence of that approval.
If applying a proposal required me to also amend a .intent/ rule, add a new service account, or widen a scope — those downstream actions are outside the perimeter. CORE's record ends at "approved by Dariusz at timestamp X." The induced state change that followed is not in the log.
But here's the thing: that gap is not an oversight in CORE's design. It's a consequence of something more fundamental.
.intent/ Is a Shim
.intent/ — CORE's constitutional layer, the directory of rules, worker declarations, and workflow stages that governs everything CORE does — is currently hand-authored YAML. Every file in it was written by me, under time pressure, as a working approximation of what a proper governance-policy tool would generate.
The CORE-policy-governance-writer doesn't exist yet. I haven't had time to build it. What exists instead is a shim: YAML that holds the shape of the intended thing while the tooling catches up.
This matters because of what .intent/ is in the architecture. It's not configuration for CORE. It's the constitutional layer that CORE is. The rules, the worker mandates, the workflow invariants — these are the law CORE enforces. And the Final Invariant applies there with equal force:
Every change to .intent/ must be as traceable, as defensible, as auditable as any change to src/.
Right now, it isn't. A change to .intent/ is a git commit I made. It's not a governed action. It's not logged against a finding. It's not traceable to a rule that authorized it. The authorization chain that CORE enforces rigorously for code changes simply doesn't exist yet for the policy layer itself.
That's the induced-edge gap, stated precisely. It's not that CORE fails to track what humans do after approving proposals. It's that the policy layer that would make human decisions about governance trackable hasn't been built yet. The two-log problem is the symptom. The missing tool is the cure.
The Architecture Is Self-Similar By Design
What the CORE-policy-governance-writer would be, once built, is exactly this: CORE, applied one layer up.
The same principle that governs src/ — every change must be authorized, logged, traceable, defensible — applies to .intent/. The governance writer would produce .intent/ changes as governed artifacts: triggered by a finding, authorized by a rule, logged to the blackboard, approvable or rejectable through the same proposal lifecycle that code changes use.
This is the architecture completing itself. Not a new feature bolted on, but the same invariant applied consistently at every layer. CORE governing code. A governance writer governing CORE's constitution. The loop closes.
Until that tool exists, the current .intent/ captures intent without capturing the consequences of acting on it. The authorization graph — declared scopes, permitted scope changes, human decisions that modified them — is implicit in my head and in git history, not in any structure CORE can reason over.
Daniel asked whether runtime constitutional enforcement shrinks the attack surface for induced risks. The honest answer: completely, for direct edges. Structurally, for induced edges — once the policy layer is expressive enough to represent scope changes as first-class governed events. That work is ahead of me, not behind.
What The Thread Built
Daniel's induced-edge framing gave me precise language for something I knew was missing but hadn't named cleanly. The two-log problem. The different decay rates of direct versus induced edges. The irreversible-by-default bootstrap.
CORE's append-only blackboard and proposal authorization chain solve the honest-history problem for direct edges. The CORE-policy-governance-writer — when it exists — will extend the same guarantee to the policy layer itself. Every action traceable. Every authorization defensible. Including the ones that write the law.
One person building it. Logic is consistent. The shim holds.
Daniel's piece: Agents Don't Just Do Unauthorized Things. They Cause Humans to Do Unauthorized Things.
CORE on GitHub: github.com/DariuszNewecki/CORE
Top comments (0)