The first commercial move

Turn an ambiguous AI risk discussion into an actionable system map.

Most organizations do not need another generic AI policy document. They need to know where agents are already operating, what those agents can reach, which actions create material impact, and which controls can be implemented first.

The review combines technical discovery, architecture analysis, targeted adversarial testing, stakeholder interviews, and control design. It is deliberately independent of any specific model provider or security platform.

The result is not a shelf report. Every priority finding is paired with a recommended owner, enforcement point, evidence requirement, and implementation sequence.

What you receive

Decision-ready evidence for security, engineering, and leadership.

Deliverables are written to support implementation, executive prioritization, customer assurance, and a focused production pilot.

Agent and tool inventory

Production, pilot, embedded, employee-operated, and third-party agents mapped to owners, models, tools, MCP servers, environments, and business purposes.

AI Action Graph

A visual map connecting agents to identities, credentials, data stores, APIs, tools, approval points, downstream systems, and business impact.

Authority and credential analysis

Findings on inherited user access, service accounts, long-lived tokens, broad scopes, tenant boundaries, and privilege paths.

High-impact action register

Prioritized actions that move money, change code, alter records, expose data, contact external parties, or create regulated decisions.

Targeted adversarial tests

Focused testing for prompt injection, goal hijacking, tool misuse, metadata poisoning, cross-tenant access, approval bypass, and chained actions.

Human approval map

Recommended approval thresholds, accountable roles, evidence requirements, escalation paths, and separation-of-duty controls.

Containment and response plan

A practical kill-switch design for selective revocation, safe mode, evidence preservation, incident ownership, and controlled restoration.

90-day control roadmap

A sequenced implementation plan with owners, dependencies, quick wins, policy patterns, pilot scope, and measurable success criteria.

Assessment domains

Follow the full path from agent intent to system effect.

The review focuses on enforceable controls and evidence—not abstract model evaluation disconnected from business actions.

Domain	Questions answered	Example evidence
Inventory and ownership	Which agents exist, where do they run, and who is accountable for each one?	Repositories, deployments, workflow definitions, model configurations, business owner interviews
Identity and delegation	Can the organization resolve the agent, initiating human, application, and delegated authority?	Identity claims, service accounts, OAuth grants, token scopes, impersonation paths
Tools and MCP	Which tools can be called, how are they described, and where are trust boundaries enforced?	MCP server manifests, tool schemas, transports, gateways, server code, dependency inventories
Data access	What sensitive data can enter context, be retrieved, transformed, disclosed, or persisted?	Data classifications, retrieval indexes, database permissions, logs, DLP rules, tenant filters
Action controls	Which actions are allowed, denied, constrained, rate-limited, or human-approved?	API scopes, business rules, transaction limits, workflow states, approval records
Observability and evidence	Can investigators connect intent, identity, policy, data, tool use, approval, and outcome?	Action logs, model references, gateway records, approval events, downstream system logs
Containment and recovery	Can the smallest affected component be disabled quickly and restored safely?	Runbooks, revocation controls, safe-mode procedures, evidence preservation, exercises
Governance and assurance	How are changes reviewed, controls tested, exceptions approved, and evidence reported?	Policies, change records, risk acceptance, security questionnaires, framework mappings

Typical engagement

A focused process measured in days, not quarters.

A standard review is structured around ten business days. Complex environments or deep testing can be extended by mutual agreement.

DAYS 1–2

Scope and discovery

Confirm business objectives, workflows, systems, stakeholders, access methods, and evidence sources.

DAYS 3–5

Map and analyze

Build the action graph, trace authority and data paths, and identify high-impact actions and control gaps.

DAYS 6–8

Test and design

Run targeted adversarial tests and convert findings into enforceable policies, approvals, and containment controls.

DAYS 9–10

Decide and sequence

Deliver the executive briefing, technical findings, action graph, prioritized roadmap, and recommended pilot.

Best-fit organizations

Designed for teams moving beyond experimentation.

The review creates the most value when at least one agent can access meaningful enterprise data or take an action that affects customers, code, money, operations, or regulated processes.

Early-stage prototypes can still benefit when a team needs a control architecture before production or must answer enterprise customer security questions.

AI-native software vendors

Prepare agent features for enterprise security review, cross-tenant scrutiny, and production deployment.

Regulated enterprises

Establish inventory, authority, evidence, approval, and incident controls across decentralized AI initiatives.

Security and platform teams

Align engineering, identity, data, GRC, privacy, incident response, and business owners around one control model.

After the review

Convert the highest-value finding into a controlled production pilot.

The recommended next step is usually one or two workflows behind an agent and MCP tool-call policy gateway, accountable approvals, selective revocation, and a complete action ledger. A portion of the assessment fee may be credited toward a qualifying annual platform agreement when stated in the final proposal.

Request scope and availability Use the free checklist first

Review questions

Clear boundaries before the engagement starts.

Does the review require source-code access?

Not always. The scope can begin with architecture, configurations, tool schemas, identity and data controls, logs, and stakeholder interviews. Source-code review is recommended for custom agent orchestration, MCP servers, authorization logic, or sensitive tool wrappers.

Will you test production systems?

Only under a written, mutually approved test plan. Adversarial work should normally begin in a representative non-production environment with test identities, data, transaction limits, monitoring, and explicit stop conditions.

Is this a compliance certification?

No. The review can organize findings and evidence against widely used AI security and governance frameworks, but it is not an audit opinion, legal determination, or certification.

What does the client need to provide?

An accountable sponsor, technical and security contacts, workflow documentation, representative access to agreed systems and evidence, and timely participation in discovery and readout sessions.

Can the scope cover third-party AI vendors?

Yes. The review can include third-party agents, embedded AI features, model providers, MCP servers, SaaS integrations, and vendor evidence, with testing limited to what the client is authorized to assess.

Know what your AI can do before an attacker does.