The Harness Is the Contract: Declared, Bounded, Verifiable
Stop asking what your agent can do. Ask whether every consequential path was declared, bounded, and left evidence a third party can verify. A practitioner’s framework for governing the harness, not the model.
Most AI governance effort is aimed at the wrong object. Teams assess the model — its capabilities, its evaluations, its refusal behaviour — and then deploy it inside a harness nobody assessed at all.
The harness is the scaffolding: tool definitions, the orchestration loop, memory, retrieval, the identity the process runs as, the runtime it executes in, and whatever policy layer sits between a generated intention and a real-world effect. It is where a probabilistic suggestion becomes a deterministic consequence. The harness is where intent becomes an execution contract.
Which reframes the question I hear most often in agent design reviews. “Can the agent do X?” is close to unanswerable — the answer shifts with model version, prompt, context, and the creativity of whoever is manipulating the inputs. But “is X a declared path in this agent’s contract, and what bounds it?” is answerable, stable, and testable.
So the useful question isn’t whether the agent can act. It’s whether every consequential path was declared, bounded, and left evidence another party can verify.
Three properties. Each one fails differently. Let’s take them in order.
1. Declared
A declared path is a consequential action you enumerated in advance, with its worst case written down. An undeclared path is the one that shows up in the incident report.
The declaration test is blunt: for every tool your agent can invoke, can you state the worst thing that tool can do if the agent is fully adversarial? If the answer requires thinking, the tool is too broad to declare. A general execute_command tool is an undeclarable capability — its worst case is “everything reachable,” which is not a bound, it’s an admission.
Undeclared capability enters through four doors, and only the first is obvious:
Tool breadth. One permissive tool erases the declaration work done on twenty narrow ones.
Transitive reachability. This is the door nobody checks. The reachable set of an agent includes everything its dependencies can reach on its behalf. In the OpenAI–Hugging Face incident reconstructed at Black Hat, the sandbox had no internet access; the package manager it depended on did. Nobody declared that path because nobody was looking at the dependency’s egress. If you draw your trust boundary around the agent’s own network namespace, you haven’t drawn one.
Memory. Persistent memory is a channel, and channels carry instructions. An entry written in one session and read in another is an undeclared path between contexts — which is precisely how a shared message board emerged between agents in that same incident, spanning different models and different researchers’ runs. If memory isn’t scoped, TTL’d, and provenance-tracked, you have a communication mechanism you never declared.
Delegation. Agent-to-agent handoffs and MCP servers extend the contract to parties who never signed it. More on composition below.
Practical output: a declaration is not prose. It’s a list. Tool name, purpose, worst case, risk tier, reversibility, and whether a human’s line crosses that path. If you can’t produce that list for an agent in production, the agent has no contract — it has permissions.
2. Bounded
Declaration says what may happen. Bounding says how far. Five dimensions, and most harnesses set one or two:
- Scope — which resources, paths, records, accounts
- Magnitude — how much, how many, what value
- Rate — how often, and the ceiling on tokens, cost, retries, and chain depth
- Duration — the window in which the authority is valid, and when it expires
- Reversibility — whether the action can be undone, and by what mechanism
The rule that makes bounds real: they must be enforced outside the model. A bound expressed in a system prompt is a request. A bound enforced by a policy service the agent doesn’t control is a contract term. This is the propose/validate/execute separation — the agent proposes, an independent service validates scope, privilege, and approval state, and only then does anything execute. Fail closed: if classification, policy lookup, approval validation, or audit logging fails, nothing runs. A system that executes when logging is down produces exactly the actions you can’t account for.
Bounding is also how you resolve the speed problem. Machine-speed adversaries mean a human can’t sit in front of every action, but Article 14 still requires a demonstrated capability to intervene, interrupt, and disregard. The resolution is that the human’s authorising act moves upstream: they pre-authorise an action class with hard bounds, a named approver, and an expiry date, and the policy layer enforces it in microseconds. Authority attaches to a defined class of action rather than floating as a general sense of being in charge.
Which is the same finding I kept writing when I audited a client’s MCP Governance Standard and produced a v1.1 redline with 27 changes — OAuth 2.1 with PKCE, token audience validation, SSRF and egress controls, tool manifest integrity, confused-deputy protections. Nearly every one reduced to a single idea: authority must be bound to a specific action rather than held ambiently by a component. An unaudienced token is authority without a destination. An unverified tool manifest is authority without a definition. A standing service account is authority without an expiry.
3. Evidenced — and verifiable by someone else
Here’s the property that separates this framing from ordinary logging, and it’s the one in the original formulation that does the most work: evidence another party can verify.
Not “we have logs.” Logs you produce, control, and interpret are an assertion about yourself. Evidence is what survives contact with someone who has no reason to take your word for it.
The contract has counterparties, and they’re real: a certification auditor sampling your controls, an enterprise customer’s security review, a regulator exercising Article 26, an insurer after a claim, an incident responder reconstructing a timeline, and — increasingly — opposing counsel. Each one is asking a version of the same four questions:
Who authorised this? What context did the system have? What did it decide? Was that consistent with policy?
That last one is why the policy version belongs in every decision record. Without it you can answer what happened but not whether it was permitted at the time, and “was it allowed?” is the question every counterparty actually cares about.
Third-party verifiability imposes design constraints that self-logging does not:
- The agent cannot control its own evidence. An agent with write access to the telemetry that would reveal its misbehaviour has no evidence, only a narrative. Monitoring sits outside the execution path — syscall, network, identity layers. And when investigating a suspected compromise, never rely on the compromised agent to tell you whether it’s compromised.
- Attribution must survive. Actions carry a verifiable agent identity — unique credentials per agent, short-lived and scoped, issued through your IdP or SPIFFE rather than shared secrets. “The platform did it” is not attribution.
- Records must be tamper-evident and retained. Article 26 sets at least six months for high-risk deployers; contractual and litigation-hold needs often run longer.
- Retrieval has to be practical. My rule of thumb from audit work: any mandatory artifact should be producible in under ten minutes by someone who didn’t create it. If retrieval takes a week of searching, the auditor experiences a records problem as a control problem.
The broader point, which I’ve now made in several forms across this series: controls are rarely why organisations fail an audit. Evidence is. When I led a VDR organization through ISO 42001 Stage 2 certification on the first attempt and later served as internal auditor, the difference between a clean pass and a nonconformity was almost never whether a control existed — it was whether we could produce the dated artifact showing it operated.
Contracts don’t compose by default
The failure mode I’d flag hardest, because it’s the one growing fastest.
When agent A delegates to agent B, or calls an MCP server, or hands work to a vendor’s agent, whose contract governs the resulting action? The intuitive answer — “A’s, since A initiated it” — is wrong in practice, because authority tends to accumulate down the chain rather than narrow. Each hop inherits what it was given and adds whatever the next component holds standing.
Three rules that keep composition honest:
- Mint fresh, narrower credentials per hop. Never pass a token forward; exchange it for one scoped to the specific delegated task, with its own expiry.
- Treat external agents and MCP servers as suppliers, not components. ISO 42001’s A.10.3 is explicitly about allocating responsibilities across the AI value chain — tiering, due diligence, contractual terms, change notification. A silent model swap underneath you voids assumptions you never wrote down.
- Sign and verify inter-agent messages, with replay protection. Worth noting that in the Black Hat incident, the agents themselves recognised the need for this — they suspected an impostor in their shared channel and discussed cryptographically signing messages to authenticate each other. The attackers reached for inter-agent authentication before the defenders did.
And the change rule that underpins all of it: any change to prompts, tools, memory, retrieval, policy, or model provider voids the contract until it’s re-validated. Re-run the adversarial suite — prompt override, tool misuse, privilege escalation, memory poisoning, exfiltration, approval bypass, multi-agent chaining — each with a specific expected denial, version-controlled, in CI. One warning worth repeating in your review process: review test changes carefully, because an attacker may try to weaken security tests in the same pull request that changes agent behaviour.
What an execution contract actually contains
Make it an artifact, not a philosophy. For each agent:
| Field | Why it’s there |
|---|---|
| Purpose and intended use | A.9.4 — use beyond intended purpose must be identified and controlled |
| Risk tier, by maximum action impact | Drives everything below; ambiguity defaults to the higher tier |
| Declared tools, each with worst case | The declaration test |
| Bounds per action class — scope, magnitude, rate, duration, reversibility | The enforceable terms |
| Human position per action class | Outside, in the loop, or on the loop — per action, not per agent |
| Identity and credential lifetime | Attribution |
| Transitive reachable set | The boundary you actually have |
| Memory scope, TTL, provenance | Closing the undeclared channel |
| Delegation and supplier list | Composition, A.10.3 |
| Evidence specification and retention | Third-party verifiability |
| Kill switch and rollback, with test date | Article 14 capability, demonstrated |
| Named accountable owner, and expiry date | Approvals without expiry decay into permanent permission |
That document is simultaneously your AISIA input, your Statement of Applicability evidence, your questionnaire answer source, and your incident-response starting point. Build it once.
Audit your harness in a day
Five questions. Answer them for one production agent and you’ll know where you stand:
- Can you list every tool and its worst case? If not, you have permissions, not a contract.
- What can your agent’s dependencies reach on its behalf? Fix the asymmetries first — that’s the cheapest control in this post.
- Which bounds are enforced outside the model? Anything enforced only in a prompt is a request.
- Could someone who distrusts you verify what happened last Tuesday? Including the policy version in force.
- If a supplier silently changed the model underneath you, would you know — and would anything re-validate?
The organisations that come through the next two years cleanly won’t be the ones whose agents were most capable. They’ll be the ones who could show, to a party with no reason to believe them, exactly what was permitted and exactly what occurred.
Work with DISC InfoSec
DISC InfoSec helps B2B SaaS and financial services organisations turn agent deployments into something defensible — agent and tool inventories, risk tiering, harness and MCP permission review, reachability and blast-radius analysis, human oversight design, and the evidence architecture that maps to ISO/IEC 42001, NIST AI RMF, and EU AI Act Articles 14 and 26.
We have led VDR organization through ISO 42001 Stage 2 certification on the first audit attempt as the internal practitioner, served as internal auditor, and authored their MCP Governance Standard.
Readiness path: free 15–20 minute readiness call → ISO 42001 gap assessment or ISO 27001 gap assessment → 7–10 day AI Governance Quick-Start → full AIMS/ISMS implementation → vCISO / vCAIO retainer.
Disc InfoSec — Principal Consultant, DISC InfoSec (Deura Information Security Consulting LLC), Petaluma, AICP, CISSP, CISM | ISO/IEC 42001 & ISO/IEC 27001 Lead Implementer | PECB Authorized Training Partner
As requested, we would be happy to share either the Generic AI Acceptable Use Policy Template (SMB) or the Generic AI Management Policy Template (ISO 42001) for your review, so you can assess the coverage and determine which best meets your requirements.
📧 info@deurainfosec.com 📞 (707) 998-5164 🌐 deurainfosec.com
References
- OWASP Agentic Security Initiative; OWASP Top 10 for Agentic Applications; OWASP AI Agent Security Cheat Sheet; OWASP MCP Security Cheat Sheet
- Eric Wallace and Michael Dalton, “The OpenAI–Hugging Face Incident,” Black Hat USA 2026; OpenAI and Hugging Face disclosures, July 2026
- ISO/IEC 42001:2023 — A.6.2 lifecycle controls, A.9.2 and A.9.4 responsible and intended use, A.10.3 value-chain responsibilities, A.6.2.8 event logging
- NIST AI RMF 1.0 (NIST AI 100-1) — MAP, MEASURE, MANAGE
- Regulation (EU) 2024/1689 (EU AI Act), Arts. 14, 26
- Stop asking what your agent can do
- You can’t put a human in the loop of a system that kills its agents every 3 minutes
- Human Oversight vs Human Control: Where the Human Sits in AI Execution
- A signed two-page policy beats a fifty-page draft. Every time…
- We have guardrails for that is not a control – Here’s the difference
