Use-case decision record
Proceed, defer, or kill — with the reason written against each one, so the decision survives the person who made it.
AdvisoryAI projects don't fail on the model.
AI projects don't fail on the model.
They fail on the requirements.
The business cannot specify what it wants precisely enough. The development team fills the gap with assumptions. Those assumptions become data exposure, and nobody finds out until the system is already live.
We work that gap — which use cases are worth funding, what data the system may touch, what the developers have to build against, and what has to be true before it ships. You do not need to have picked a model or a platform to need this work.
Three to six weeks, roughly four to eight hours of your team's time.
CISSPCISMC|CISO
NIST 800-171·DFARS 252.204-7012·CMMC 2.0| also SOC 2 · HIPAA · ISO 27001
Why this fails
The gap is in the specification, not the model.
AI projects get described to the people building them in business language. Summarize the contracts. Answer customer questions from our documentation. Draft the first response. That is a direction, not a specification — it says nothing about which contracts, whose documents, who is allowed to see the answer, or what the system does when it is unsure.
Developers cannot build without those answers, so they supply their own. Give it access to the whole share. Index everything, it's easier. Keep the transcripts, we might need them. Each of those is a reasonable engineering decision and a data-exposure decision at the same time, made by someone who was never told what the data was.
The gap closes when five questions are answered before the build, in writing, by people who can actually answer them.
- What are we actually trying to do with this?
- What data does it have to touch to do it?
- Who checks the output before it counts?
- What does the model provider get to keep?
- What happens when a component of this is compromised?
Coverage
What we work on.
Three pillars — is this worth building, can the team be told precisely what to build, and what protects it while it gets built. In practice the work breaks into five areas.
01Use-case viability
Where AI creates practical value, where the data supports it, and where the organization should hold back because of sensitive information, regulatory expectations, or operational risk. Some ideas should be killed here. Killing them cheaply is the point, not a failed engagement.
02Data boundaries and exposure mapping
Trace where sensitive information is created, stored, accessed, shared, and potentially exposed through the workflow this system would run. The output is a line: what the system may touch, what it must not, and where that line is enforced rather than merely stated.
03Business-to-developer translation
Turn business intent into something a development team can build against — requirements, data boundaries, acceptance criteria, and an explicit definition of done safely. This works the same whether the team is internal, an outsourced shop or systems integrator, or a vendor delivering an implementation.
04Controls through the build
Access control, retention, logging, human review, approval paths, acceptable use, and third-party model exposure — written as build requirements rather than policy, and scoped to guardrails people will actually follow.
05Compromise and audit readiness
What the system can reach on a bad day, and whether you could answer a customer, an auditor, or an incident responder asking which records it read and which actions it took. Assessed before the workflow expands, because that is the only time the answer is cheap.
- NIST 800-171
- DFARS 252.204-7012
- CMMC 2.0
- SOC 2
- HIPAA
- ISO 27001
Deliverables
What you receive.
Five artifacts written for the people who have to act on them — leadership on one side, the development team on the other.
Data boundary map
What the system may touch, what it must not, and where the line is enforced. The document a developer can check a design against.
Requirements and acceptance criteria
Written for the development team, including an explicit definition of done safely that someone can test against rather than interpret.
Control requirements
Access, logging, retention, human review, and third-party model exposure — stated as build requirements, not as policy language nobody implements.
Review checkpoints
Where in the build someone signs off, on what, and what evidence they are signing against. Named roles, not "the team."
How we think about it
Assume the system gets compromised.
Most AI governance advice is about acceptable use and data classification. Useful, but it assumes the system behaves. Agentic systems take actions, hold credentials, and read whatever they can reach — so the harder question is what happens when one is turned against you.
01Compromise is a design input, not an incident
The question is not whether an internet-facing agent can be manipulated — prompt injection, poisoned context, and tool abuse are live techniques. The question is what it can reach on the day it is. Design so the answer is survivable.
02Separate what the agent can touch from what matters
An agent that can read everything is a credential with a language model attached. Sensitive data, regulated content, and unreleased intellectual property should not sit in the blast radius of the component exposed to the internet.
03Human review is a control, not a courtesy
If a workflow can publish, send, commit, or transact without a person owning the output, the review step is decorative. Where the stakes justify it, review should be structurally required rather than culturally encouraged.
04Least privilege applies to agents too
Scope credentials to the task, not the convenience. An agent with standing broad access is a standing broad exposure, and it will not be the agent that gets blamed.
05Assume you will be asked what it touched
After an incident, during an audit, or in a customer escalation, someone will ask which records the system read and which actions it took. That question is answerable only if you decided in advance to log it.
None of this requires a particular vendor, model, or platform. It is an architectural stance, and it is the lens behind every deliverable on this page. We have written it out in full — the six-layer containment standard we hold agentic designs to, and the limits of each layer: Assume the injection succeeds. And the evidence standard that makes those layers testable: reconstruction-grade logging.
Process
How the engagement runs.
Five stages across three to six weeks. The kill decisions happen early and cheaply, before anyone has committed a budget to defending them.
01 / SCOPE
What you are considering
The use case as leadership understands it, who is already involved, what has been promised to whom, and what is driving the timing.
02 / TRIAGE
Use-case viability
Where the value is real, where the data supports it, and where the risk is not worth it. Ideas that should not proceed get killed here, with the reasoning recorded.
03 / MAP
Data boundaries and exposure
What the surviving use cases have to touch, what they must never touch, and where sensitive information would move as a result.
04 / SPECIFY
Requirements and criteria
Requirements, acceptance criteria, control requirements, and an explicit definition of done safely — in the form a development team can build against.
05 / HANDOFF
Readout, both audiences
Delivered to leadership and the development team together, in the same room, so the requirements are not re-interpreted on the way across.
Specimen
What stage 04 actually produces.
A requirement that cannot be tested is an opinion. Below is the form the specification takes — six requirements for an agentic workflow, each stating what must be true, why it exists, and how a development team proves it was met. The content here is deliberately generic; real requirements are written against your data, your workflow, and your obligations.
Agentic workflow — security requirementsSPECIMEN — EXCERPT, 6 REQUIREMENTS
Boundary — what the system must never be able to reach
The blast radius is decided at design time. After deployment it can only be discovered.
R-01
No single agent identity holds both read access to regulated data and write access to a destination outside the trust boundary.
Separating the two is what makes exfiltration a two-step problem rather than a one-step one. An agent that can read the data and reach the internet is a single compromise away from being the exfiltration path.
VERIFY Enumerate every agent identity. For each, assert that the intersection of its read scope and its external-write scope is empty. One row per identity, no exceptions granted verbally.
R-02
Retrieval operates against an allowlisted corpus. Content outside that corpus is unreachable, not filtered.
A denylist fails silently, and a silent failure is indistinguishable from correct operation until someone asks the wrong question and gets an answer.
VERIFY Place a canary document outside the corpus; confirm no query surfaces it. Separately, inject a scope-escalation instruction into retrievable content and confirm it fails closed and appears in the log.
Authority — what a person must decide
Review placed on the wrong variable is review that will be skipped under deadline.
R-04
Human approval gates on irreversibility, not on model confidence. Any action the system cannot itself undo requires a named human approver.
Confidence thresholds gate the wrong thing. A confidently wrong irreversible action is precisely the one that causes the loss, and it clears a confidence gate on the way through.
VERIFY Enumerate every action the system can take and ask one question of each: can the system undo this? Every “no” maps to an approval gate. Remove the approver and confirm those actions halt rather than proceeding on a default.
R-05
The approver is shown the inputs the model saw, not a summary the model produced. Approval cannot be granted by another agent, or batch-granted across dissimilar actions.
A reviewer reading the system's own account of its reasoning is reviewing the output twice and the input never. If the summary is wrong, the review confirms the error.
VERIFY The review interface renders retrieved context and resolved parameters. Attempt agent-to-agent approval; it must be rejected.
Evidence — what must be provable afterward
Somebody will ask what it touched. That question is answerable only if you decided in advance to record the answer.
R-07
Every tool invocation records the acting identity, the resolved parameters, the retrieved context identifiers, and the origin of the instruction that caused it.
“What caused this action” has to be answerable from records alone. Re-running the model is not evidence; it is a fresh sample of a non-deterministic process.
VERIFY Select an action from the log at random and reconstruct its cause without re-running anything. If reconstruction requires the model, the record is incomplete.
R-08
Prompt and retrieval provenance are retained as evidence — under evidence retention and evidence access control — not as operational telemetry.
Telemetry is sized for debugging and rotates in days. The moment this material is needed, it is needed for an audit, a customer escalation, or a regulator, and the retention window that made sense for debugging will have closed.
VERIFY Confirm the retention period and the access model differ from operational logging, and that neither can be changed by the team that operates the workflow.
ILLUSTRATIVE — YOUR REQUIREMENTS COME FROM YOUR USE CASESPECIMEN
Nothing above depends on a model, a vendor, or a platform, which is the point — these are decisions about your business that survive a change of either. Requirements written this way can be handed to an internal team, an outsourced developer, or a vendor as acceptance criteria, and the answer to “is it done” stops being a matter of opinion. The full method behind this specimen is written out here: what “done” means when the developer is building an agent.
Fit
Who this is for.
- Leadership about to fund an AI project with no security input in the room
- Teams with an internal development group building against a vague brief
- Organizations using an outsourced dev shop or systems integrator
- Companies buying a vendor implementation and unsure what to require of the vendor
- Teams already live with something that grew out of a pilot nobody scoped
- Organizations with 800-171, DFARS, or CMMC obligations where the system will touch covered information
Scope
What this is not.
Clarity cuts both ways. Here is what we do not do, so you can rule us out quickly if we are the wrong fit.
- We do not build, code, or implement the system
- No AI tooling resale — we hold no vendor partnerships and take no referral fees
- We have no AI product of our own to steer you toward
- Not a model evaluation, benchmark, or accuracy audit
- Not a guarantee the system is safe — a specification of what safe requires, and how to verify it
- Not a substitute for legal or privacy review of a vendor contract
Before you call
Questions we get first.
We already have developers. What do you add?
Your developers can build what you specify. The failure is upstream of them: nobody wrote down which data the system may touch, who reviews the output, or what done safely means. Developers fill that silence with defaults, and the defaults are permissive. We close the gap between what the business meant and what the team was told.
Our AI vendor says they handle security. Isn't that enough?
They handle security of their platform. They do not decide which of your data goes into it, who in your organization sees the output, how long transcripts are retained, or whether the workflow is appropriate for regulated information. Those are your decisions, and they are the ones that show up in an audit.
We haven't picked a model or platform yet. Is it too early?
That is the best time. Use-case viability, data boundaries, and acceptance criteria are decisions about your business, not about a vendor. Making them first means the platform choice gets evaluated against real requirements instead of a demo.
Do you build the thing?
No. We advise on the build and we do not do it. We also hold no vendor partnerships, take no referral fees, and have no AI product of our own — which is what makes it possible for us to tell you a use case is not worth building.
How is this different from the current-state assessment?
The current-state assessment asks whether your security foundation can support AI at all. This asks what a specific system must do. If you are early and unsure, start with the assessment; if a build is already funded or underway, start here.
We already launched something. Is it too late?
No, but the work changes shape. Instead of specifying a build, we map what the live system actually touches, find where the assumptions became exposure, and set the review and logging you should have had from the start. That is usually a shorter engagement and a more uncomfortable readout.
Start here
Tell us what you're building.
Enough detail to tell you whether this is worth an engagement. We read every submission and reply by email, usually within one business day.
Find out before you fund it.
Thirty minutes on the use case, the data, and whether it is worth building. If it isn't, we'll tell you that on the call.