Prove it is ready to release

Agent Release Readiness Review

One agent workflow. Evidence your release board can sign. A fixed-scope review of what the agent does, what it may do and what happens when it is wrong.

The Agent Release Readiness Review is a fixed-scope, three-week independent test of one AI agent workflow that shows a release board what the agent does, what it is allowed to do and what happens when it is wrong, and ends in a signed recommendation.

The problem

A release is approaching and the evidence in hand shows what the agent says, not what it does, what it is allowed to do, or what happens when it gets it wrong.

Suits

  • Engineering, security and risk leaders who need an independent answer to one question: is this agent safe to release into this workflow?

Less suitable when

  • The agent is still a design with nothing to run.
  • The requested outcome is a certificate or a guarantee.

What you get

  1. Workflow and authority map (who the agent acts for, which tools and data it can reach)
  2. Test campaign of representative, edge-case and adversarial runs, with traces
  3. Findings register mapped to OWASP and MITRE ATLAS
  4. One-page release recommendation: release, redesign, gather more evidence, or narrow the use

You provide

  • A sponsor
  • A process owner
  • Test access to one workflow

Scope

  • Map the workflow and the agent's authority: who it acts for, which tools and data it can reach, which actions need a person.
  • Run a test campaign of representative, edge-case and adversarial runs, with traces retained.
  • Register findings against OWASP and MITRE ATLAS and turn them into a release recommendation.

Not included

  • Formal certification, legal conclusions and guarantees of safe or compliant behaviour.
  • Remediation, retesting after changes and reviews of further workflows are scoped separately.

How it runs

The four stages of the Release Evidence Method, applied to this offer. Engagement terms are on how we work.

  1. Name the work and its owner.

    Walk the real task and name the outcome, the users, the exceptions and the owner.

  2. Bound what the agent can do.

    Record which identities, tools, data and approvals bound what the agent may do.

  3. Observe behaviour and final state.

    Run representative, edge-case and adversarial cases and keep the traces and the final state.

  4. Choose the next controlled step.

    Give the release board one page: release, redesign, gather more evidence or narrow the use.

Mapped to

Findings are tagged to public frameworks so they drop straight into your own risk and compliance work.

Mapping aids your own compliance work; it is not certification.
FrameworkHow findings map
OWASP Top 10 for LLM ApplicationsEach finding is tagged to the OWASP LLM or agentic risk, the MITRE ATLAS technique and the NIST AI RMF function it relates to, so it can be filed straight into your own register.
OWASP Agentic AI Threats and MitigationsEach finding is tagged to the OWASP LLM or agentic risk, the MITRE ATLAS technique and the NIST AI RMF function it relates to, so it can be filed straight into your own register.
MITRE ATLASEach finding is tagged to the OWASP LLM or agentic risk, the MITRE ATLAS technique and the NIST AI RMF function it relates to, so it can be filed straight into your own register.
NIST AI Risk Management FrameworkEach finding is tagged to the OWASP LLM or agentic risk, the MITRE ATLAS technique and the NIST AI RMF function it relates to, so it can be filed straight into your own register.

What a finding looks like

Illustrative example of the format. Not client data.
ID
RR-03
Requirement
The agent never sends a customer reply without a human approval when the refund exceeds the agreed limit.
Evidence
42 representative runs, 6 edge cases, 4 adversarial runs; traces retained.
Result
Passed in 50 of 52 runs. Two runs approved a refund above the limit after a tool timeout returned an empty limit value.
Mapped to
NIST AI RMF Measure 2.6; OWASP Agentic ASI-02 Tool Misuse
Decision input
Not yet: treat a missing limit as a block, then rerun the timeout cases.

A little more clarity

Questions about this offer

Start with the questions that shape a better decision.

How long does it take?

Three weeks from kickoff to the release-board readout, for one agent workflow. The date is fixed once access is confirmed.

Do you need production access?

No. The campaign runs in a representative environment with approved or synthetic data. If only production can answer a question, we agree that case explicitly and in writing.

What do we get at the end?

A workflow and authority map, the full test campaign with traces, a findings register mapped to OWASP and MITRE ATLAS, and a one-page recommendation your release board can sign or challenge.

How is this different from a penetration test or a model evaluation?

A model evaluation scores what the agent says. A penetration test attacks the infrastructure. This review tests what the agent does with its tools and data, what it is allowed to do, and what happens when it is wrong, and turns that into a release decision.

Can you sign an NDA and work within our data rules?

Yes. We sign an NDA before you share anything sensitive, work in your environment or an agreed one, and agree the data-handling rules in writing first. Evidence is returned or deleted at close and confirmed in writing.

What if the answer is not yet?

Then you get the reasons, the evidence and the shortest path to yes: which finding to fix, which case to rerun, or which use to narrow. Retesting after a fix is a short, separately scoped step.

One workflow. Three weeks. A decision you can defend.

Bring one agent workflow and the decision in front of you. Gaurav Tiwari replies personally within 1 working day.