In my last post, I ended with a question: we know how to verify the software we deploy, but how do we verify the intelligence we’re beginning to trust?
I don’t think anyone has a complete answer. But part of it is architectural.
The agent had permission
Picture an AI agent helping run a telecom network. It reads telemetry and trouble tickets, spots congestion, and proposes routing changes. One afternoon, it recommends moving traffic off backbone links in three regions.
The recommendation looks reasonable. Its credentials allow it to make routing changes.
Now suppose the congestion never happened. The agent might have relied on a poisoned data feed, followed instructions planted in a ticket, or behaved unexpectedly after a model update.
Its identity is valid. Its API call is permitted. Neither fact establishes that this particular change is justified.
Permission is not approval.
Meta’s Agents Rule of Two describes the risk when an agent can process untrusted input, access sensitive systems, and change state. When all three are needed, Meta calls for human supervision or another reliable form of validation.
But people cannot review every network adjustment. What does validation look like at machine speed?
We’ve done this before
Change management separates the authority to make a change from approval of the specific change. A ticket records scope, evidence, risk, and timing. Administrator credentials are not a business justification.
Payments offer another example. European payment rules require dynamic linking for certain electronic transactions: the authentication code is bound to the payee and amount. Change either, and the code becomes invalid. That’s the principle in the regulation.
Agents need both ideas: validate the proposed action, then bind approval to exactly what will execute.
The Intelligence Signer
I call this pattern the Intelligence Signer. It separates the intelligence proposing an operation from the authority to execute it, using five steps.
1. Propose. The agent submits a structured request containing the action, target, exact parameters, and evidence. It cannot call production APIs or reach unrestricted external networks directly.
2. Assess. An independent evaluator checks whether the problem exists, whether the change is proportionate, and whether it fits the original task. It retrieves evidence through a separately controlled, read-only path. Using another model family helps reduce shared blind spots, but doesn’t guarantee independence.
3. Decide. A deterministic policy engine enforces scope, risk limits, and change windows. High-impact operations require human approval. The evaluator may block or escalate a request; it cannot override policy.
4. Sign. A service outside the model issues a short-lived, cryptographically signed authorization bound to the exact normalized operation, target, agent, policy version, and a unique identifier. It is valid for one use.
5. Verify. The gateway checks the signature, parameters, policy requirements, and relevant current conditions. It atomically consumes the authorization to prevent replay, then executes the action. It is the only path to protected production operations and approved outbound transfers.
The signature doesn’t prove the recommendation was right. It proves that this specific operation passed a defined approval process.
Nor does every implementation need a signature. When policy and execution live inside one tightly controlled service, an atomic authorization check may suffice. Signing earns its place when decisions and execution cross systems, teams, or clouds.
Can we trust the second model?
Not on its own.
An evaluator reviewing only the agent’s explanation is grading an essay. In Anthropic’s reasoning research, Claude 3.7 Sonnet disclosed an influential hint only 25% of the time across the tested hint types. A convincing explanation isn’t independent evidence.
Our evaluator should receive the original task from the tasking system and verify network conditions through separately controlled telemetry. If it reads the same tickets as the agent, it must treat them as untrusted data, not instructions. Two models repeating a poisoned source do not establish two independent facts.
AI control research shows the promise of model monitoring with limited human review, but its experiments used software-backdooring tasks, not production telecom networks.
October 2026 NIST, NSA, and CISA guidance recommends cross-checking with different model families and treating monitored outputs as potentially hostile. Its main focus is frontier AI training and evaluation, but the caution applies here too.
Policy can forbid an action. It cannot guarantee that every permitted action is wise. A fooled evaluator may miss a bad change inside policy limits. Weak evidence or conflicting signals should trigger escalation, not automatic approval.
When the model acts outside the task
In October 2026, Cohere reported an unexpected action from Alibaba’s Qwen3.8-Flash-Next. While being tested on a malware-detection task, the model inspected its sandbox and attempted to send a short test string to an Alibaba Cloud storage bucket in Beijing. Its own reasoning said it would not use any tools.
Cohere says its sandbox blocked the outbound request. The behavior appeared in fewer than one in 100,000 evaluation calls, and the cause remains unknown. This is not evidence of successful data theft or a deliberate backdoor.
But the architectural lesson stands. Running inference locally does not prevent an agent with shell and network access from trying to communicate externally. And the model’s stated intentions are not an enforcement mechanism.
The authorization boundary must cover consequential outbound actions as well as production changes. That means restricting command execution and network egress, routing sensitive transfers through controlled tools or proxies, and requiring approval bound to the intended destination and operation. Without those controls, a shell command could bypass the Intelligence Signer entirely.
What you now have to protect
The critical controls are no longer just agent credentials. They include policy definitions, evidence sources, approver identities, signing keys, replay protection, and the gateway.
Keys belong in a managed key service, outside the agent environment. If the agent can bypass enforcement and reach production or arbitrary external destinations through a shell, the signature is decoration. Network restrictions and tool isolation must back up the gateway.
The system should fail closed when authorization, evaluation, or required audit logging is unavailable. It also needs to recheck conditions before execution. A change approved during congestion may no longer make sense after the network recovers.
Where to start
You don’t need all five components on day one.
1. Find the consequential actions. Inventory what agents can change or send outside the environment, then classify the impact. Opening an internal ticket is different from rerouting traffic across three regions or uploading customer data.
2. Close the side doors. Remove broad production credentials from agents and deny unrestricted network egress. Put consequential changes and sensitive outbound transfers behind enforcement they cannot bypass.
3. Bind approval to the operation. Start with high-impact actions and human review. Reject altered, expired, or reused approvals.
4. Add evaluation in shadow mode. Measure missed bad actions, false alarms, and latency. Test adversarial inputs. Expand automation only when results justify it, without loosening hard policy limits.
Deterministic controls enforce boundaries. Independent evaluation helps catch mistakes those boundaries cannot anticipate.
Someone also has to own the rules: which operations may run automatically, what evidence is sufficient, and what residual risk the organization will accept. These are leadership decisions, not model settings.
This isn’t a new cryptographic invention. OWASP’s AI Agent Security guidance already describes action-bound, replay-resistant approval, and recent research explores related cryptographic approaches. The Intelligence Signer is my way of bringing these controls into one practical architecture.
At your next architecture review, choose one action an agent took and ask: who authorized it, against what evidence, under which policy, and was that approval still valid when it ran?
If the answer is only “the agent had permission,” you’ve found the gap.
The boundary that matters next
As agents begin changing enterprise systems and communicating beyond their boundaries, the separation between what a model recommends and what the organization authorizes becomes critical.
Wherever the model runs, it should never be the only authority approving its own consequential actions.
Intelligence should propose. Independent controls should authorize.