M.A.D.E. · MAP
Connected System Context
Build the connected system model before you test the flows.
Identify the applications, models, prompts, data stores, retrieval systems, agents, tools, identities, credentials, permissions, providers, controls, and trust boundaries that determine how the AI product can behave and where security failures can emerge.
Map creates the connected context every later security decision depends on. Architecture, intended flows, authority relationships, control ownership, and evidence gaps become a reviewable baseline for Attack, Defend, and Evidence.
Connected context
Map once. Carry the context through the full lifecycle.
Mapping is not documentation for its own sake. The same connected context informs Code Scanner prioritization, adversarial scenarios, Authority Graph analysis, attack-path grounding, control design, retest conditions, and final evidence.
MAP
Connected system, flow, and authority context
ATTACK
Which flows and candidate paths require testing?
DEFEND
Which control or authority boundary changes the outcome?
EVIDENCE
What evidence supports the conclusion?
Capabilities
What the connected system model makes visible.
System architecture
Applications, models, APIs, SDKs, gateways, vector stores, retrieval systems, MCP servers, agents, tools, browser surfaces, identities, controls, and external providers.
Trust boundaries
Where identities, tenants, sensitive data, model providers, retrieval contexts, tools, credentials, approval decisions, and external systems cross security or ownership boundaries.
Retrieval and data flows
Model query handling, authorization, retrieval, provenance, policy checks, context assembly, model invocation, output handling, and downstream actions before testing for leakage, poisoning, or boundary failure.
Agent authority
Model what agents, identities, service accounts, credentials, tools, and workflows can read, write, send, execute, approve, administer, or change—including approval gates and external effects.
Ownership and release gates
Identify who owns each component, flow, control, exception, remediation decision, and release gate before security work becomes organizationally orphaned.
Evidence gaps
Expose missing architecture records, runtime telemetry, ownership, control mappings, approval records, test evidence, remediation state, and buyer-facing support before they become blockers.
The system is the attack surface.
AI risk rarely sits inside one model, prompt, or endpoint. It emerges from relationships among applications, identities, agents, tools, data, permissions, approval gates, controls, and external effects.
Connected System and Authority Topology
Security-relevant behavior emerges from relationships among users, agents, identities, data, retrieval systems, tools, controls, approval gates, and external actions.
Graph of a user, agent, retrieval corpus, tool, approval gate, service identity, and external action with explicit trust and authority relationships.
Map makes those relationships explicit so later analysis can distinguish ordinary system complexity from dangerous combinations of authority, trust, data flow, and control weakness.
Workbench capabilities that support Map
The connected context that feeds Attack, Defend, and Evidence.
Threat Canvas
Model architecture, trust boundaries, data movement, controls, ownership, and candidate abuse scenarios in one reviewable canvas.
Authority Graph
Model how agents, identities, credentials, tools, permissions, approvals, and consequential actions compose into effective authority.
Code Scanner
Find AI-specific code findings and code-risk paths across LLM applications, RAG, agents, MCP, tool calling, model integrations, and security boundaries, then carry supported results into Attack.
Surface Discovery
Discover AI applications, providers, SDKs, prompts, agents, tools, retrieval systems, browser signals, and external boundaries that contribute to the connected system model.
Trust Scanner
Review public AI, security, governance, legal, and SDLC claims for coherence, support, and evidence gaps.
Mapping should produce bounded test priorities, not a static diagram.
The output of Map is a bounded set of system entities, intended flows, trust boundaries, authority relationships, evidence gaps, and candidate abuse scenarios that Attack can test and qualify.
Map-to-Attack Handoff
Mapped assets, authority, and trust boundaries become bounded attack hypotheses and a prioritized test plan.
Transformation figure showing mapped system evidence becoming bounded hypotheses, test priorities, and evidence requirements.
This handoff keeps adversarial testing tied to the actual application and prevents Attack from becoming a generic checklist of prompts or payloads.
MAP
Model & Baseline
Understand architecture, data flows, trust boundaries, authority, ownership, controls, and evidence gaps.
Open routeATTACK
Exercise & Qualify
Test realistic failure flows, capture traces, and determine which supported conditions form consequential paths.
Open routeDEFEND
Harden & Verify
Change architecture, authority, controls, and approval boundaries, then verify the original failure no longer succeeds.
Open routeEVIDENCE
Preserve & Reuse
Preserve findings, traces, paths, fixes, retests, control evidence, and reviewed outputs.
Open route