A practical first engagement

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 can combine technical discovery, architecture analysis, stakeholder interviews, evidence review, control design, and authorized adversarial testing. The exact methods depend on the signed scope and the access the client is authorized to provide.

The report pairs priority findings with recommended owners, control points, evidence requirements, dependencies, and an implementation sequence. Recommendations still require client validation and implementation.

What you receive

Prioritized findings for security, engineering, and leadership.

Deliverables are written to support implementation planning, executive prioritization, customer review, and an optional follow-on pilot.

Agent and tool inventory

In-scope 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 reviewed agents to identities, credentials, data stores, APIs, tools, approval points, downstream systems, and possible business effects.

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

Authorized testing for agreed cases such as 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 containment design for selective revocation, safe mode, evidence preservation, incident ownership, and controlled restoration.

90-day control roadmap

A sequenced implementation plan with proposed owners, dependencies, early priorities, policy patterns, optional 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

Illustrative working plan

A focused review with a documented schedule.

A focused review may be planned around ten business days. The actual schedule depends on scope, access, evidence readiness, stakeholder availability, testing authorization, and written 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 next step.

When the review is most useful

Use it when an agent is approaching meaningful access or authority.

The review is most useful when at least one agent can reach sensitive enterprise data or take an action that may affect customers, code, money, operations, legal rights, 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

Use the highest-value finding to define a controlled design-partner validation.

A separate design-partner pilot may be considered for one or two workflows after the review. It requires its own technical assessment, written scope, data-handling terms, testing boundaries, acceptance criteria, fees, and delivery commitments.

Request scope and availability Use the free checklist first

Engagement boundaries

Authorization and expectations are documented before work begins.

The review is designed to improve decisions, not create false assurance. The signed scope controls the work.

SCOPE

Defined systems and evidence

Only agreed agents, environments, integrations, accounts, records, and evidence sources are included. Unavailable or unreliable evidence is identified as a limitation.

AUTHORIZATION

Testing by written permission

No production or third-party testing is performed without documented authorization, targets, methods, safety controls, monitoring, stop conditions, and responsible contacts.

LIMIT

No certification or guarantee

The review is not a legal opinion, compliance certification, audit opinion, insurance determination, warranty, or guarantee that every weakness or incident path has been found.

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.

Will the review find every security issue?

No. Findings are limited by the agreed scope, available evidence, access, timing, environment, and methods. The report documents material limitations and prioritizes the issues identified during the engagement.

Map agent access, authority, and high-impact actions.