The Question a CISO Should Ask Before Adopting Agents

A board asks the CISO: we want to deploy AI agents across our customer service operation. What do we need to do?

The CISO has read the briefings. They’ve seen the vendor demos. They have a stack of frameworks on their desk — NIST AI RMF, ISO 42001, the EU AI Act, internal risk policies. They could start there.

There is a different starting question. Not what controls do we deploy? — that comes after. The first question is structural:

Are we currently extending trust to thousands of agents the way we extend trust to a handful of vendors?

If the answer is yes, the rest of the conversation is about how to keep doing that as the count goes from thousands to millions. The vendor model — paper contracts, annual reviews, SLA enforcement, occasional audits — does not scale to that count. Not in cost, not in latency, not in the number of decisions per second the agents will make.

If the answer is no — if you are already extending trust differently — then the conversation is about whether the different model you’ve adopted is the right one.

Most organisations have not picked an answer. They are running thousands of agents and treating each like a vendor that happens to act fast. The model is misaligned with the operation. The first major failure will reveal this.

Why The Vendor Model Doesn’t Fit

The vendor model has specific properties:

• Slow trust establishment. Procurement, contract, security review, integration — months.
• Coarse-grained authority. A vendor is approved for a domain (HR data, customer data, financial data) and acts within that.
• Rare verification. Audits annually; SLAs measured monthly.
• Static identity. The vendor is the vendor; their personnel may change but the vendor entity is durable.
• Negotiated scope. What they do is in the contract, signed up front.

For a few dozen vendors in your environment, this works. It works because the count is small, the actions are slow, the consequences are bounded by the procurement gate.

For agents, every property breaks:

• Trust must be established at deployment time, instantly. A new agent class is being deployed daily, sometimes hourly.
• Authority is per-action, not per-domain. An agent that processes invoices needs different authority for “summarise this invoice” vs “issue a refund based on this invoice.”
• Verification must be continuous. Every action, attested. Every output, verifiable. Audits-by-default, not audits-by-event.
• Identity is durable but authority is transactional. The agent’s identity persists; its authority for any specific action expires when the action is fulfilled or revoked.
• Scope is dynamic. The mandate that authorises today’s action may differ from the mandate that authorises the same action class tomorrow, because the entrusting party adjusted scope.

The vendor model cannot handle these. Not in principle, not in scale, not in the latency the agent operation requires. A different trust model is needed — one where trust is computed, attestation is continuous, authority is transactional, and verification runs at the speed of action.

Why “Compute Trust” Sounds Strange and Why It Isn’t

The phrase trust is computed is unfamiliar. Trust, in everyday language, is something you give or withhold. It is a disposition, not a calculation.

For agents, the disposition model breaks for the same reason the vendor model does. There are too many agents, acting too fast, in too many contexts, for any human-scale dispositional judgement to apply per-action. The disposition has to be computed — derived, in real time, from observable evidence.

What the framework calls Effective Trust is a per-action computation. Identity check, supply-chain check, behavioural baseline, attestation chain — combined into a verdict for this specific action in this specific context. The verdict is the engineered measure that stands in for trust.

The CISO’s job, in this frame, is not to give trust to agents the way they give trust to vendors. It is to commission and oversee a trust-computation pipeline that operates per-action across the agent fleet.

This is a different operational shape. The CISO is not the gatekeeper for a few dozen vendors; they are the operator of a pipeline that produces evidence-based verdicts for billions of agent actions per year. The work is different. The skills are different. The metrics are different.

A CISO who frames the question as which vendors do we approve for AI will get the question wrong. A CISO who frames it as what trust-computation pipeline do we operate, and is it producing trustworthy verdicts will be in the right conversation.

The Three Questions That Follow

Once the framing is right, three follow-up questions structure the work:

1. What does our pipeline currently compute?

Identity verification probably. Supply-chain attestation maybe. Behavioural baseline rarely. Output verification sometimes. Mandate validation almost never. Bounded execution mostly not. Forensic-ledger posture infrequently.

The honest inventory of what your pipeline produces today is the starting point. Most organisations discover their pipeline produces only 30-40% of what an agent operation requires. That’s not a failure; it’s the floor from which to plan.

2. What is the floor we need given our agent capability and consequentiality?

The capability floor depends on what your agents can do. Code execution? Financial actions? Multi-day autonomous operation? Each adds rigor requirements. The consequentiality floor depends on what an action costs when wrong — financial, reputational, regulatory, physical. Each adds rigor requirements.

The required floor is the max of the two axes. Compare to your current pipeline. The gap is the roadmap.

3. What evidence are we producing, and is it surviving?

For every action your agents take, what evidence is produced? Where does it live? Can you query it six months later for an audit? Can you replay any specific run? Can you demonstrate to a regulator that this specific action was verified at the time it occurred, and that the verification’s record is unaltered?

If the answer is yes for most actions, you are running with the right posture. If the answer is no, you are running with the appearance of safety and the absence of evidence — and the first major incident will reveal that the absence is the problem.

What Doesn’t Belong in the First Conversation

A CISO can be drawn into specific control debates immediately. Should we use this prompt-injection filter? That output classifier? This sandboxing approach?

These are legitimate questions. They are not the first question. Specific controls are downstream of the trust-computation pipeline they fit into. A great filter in a misaligned pipeline is wasted; a workmanlike filter in a well-aligned pipeline carries its weight.

The first conversation is about the model. The vendor model doesn’t scale; the trust-computation model does. Effective Trust is the per-action measure; the pipeline that produces it is the operational surface; the CISO’s job is to operate that surface.

Once the model is agreed, the specific controls become tractable: each one is evidence the pipeline produces for the per-action verdict. The debate moves from which control to what does this control contribute to our verdict’s reliability. That’s a productive debate.

The Disposition

The board asked the CISO: what do we need to do to deploy AI agents safely?

The structural answer: we need to stop treating each agent as a vendor and start operating a trust-computation pipeline that produces per-action verdicts at agent speed.

The CISO who can articulate this — to the board, to the engineering team, to the regulators — is positioned to do the actual work. The CISO who cannot articulate it will spend their tenure managing individual control debates that don’t compose into a coherent posture.

Effective Trust is the operational measure. The pipeline that produces it is the surface. The forensic ledger is the trail that survives. The capability floor is the rigor requirement. The Closure Pattern is the audit shape. Position B is the disposition that organises the safety surface.

These are the load-bearing concepts for the CISO conversation. None of them are individual controls. Together, they are the frame within which controls compose. With the frame, the work is tractable. Without it, the work is a series of unrelated decisions that don’t add up to a defended operation.

Start with the frame. The frame is the question the CISO should ask first.