PARTNERS

Add selected Workbench capabilities through bounded OEM and partner integrations

Deliverablesdeliverable
deliverable

Map Pillar Figures

Canonical figures for the Map pillar.

Public sample
Client deliverable
public-sample
System
Map Pillar Figures
Environment
Production pilot

# Map Pillar Figures

MAP-01

What Map Establishes

Map turns architecture, authority, data movement, and trust boundaries into a security model that can be tested.

Three-part figure showing system inputs, the Map capability, and the resulting testable security model.

INPUTSSystem realityArchitecture and componentsIdentity and authorityData and trustENGINEMapInventory theattack surfaceTraceconsequentialpathsMark trustboundariesExpose evidencegapsRESULTSTestable security modelExplicitrelationshipsBounded attackhypothesesReviewableownershipEvidencereadiness
MAP-02

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.

Actors and identitiesContext and dataTools and effectsUserAgentService identityRetrieval corpusSensitive dataConsequence-bearingtoolApproval gateExternal action
MAP-03

Evidence Readiness Boundary

A useful map separates observed relationships from inferred connections and explicitly exposes evidence gaps.

Diagram separating observed system relationships, grounded conclusions, review boundaries, inferred connections, and unresolved gaps.

SUPPORTED CLAIMGrounded mapConfirmed assets and actorsSupported relationshipsConfirmed trust boundariesExplicit evidence gaps1Configuration and code

Declared components, identities, routes, and policy.

2Runtime traces

Observed calls, retrieval, actions, and external effects.

3Permission snapshots

Tool, service, and delegated authority at review time.

4Challenge source sufficiency5Consider alternative explanations
MAP-04

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.

Assets and actorsAuthorityrelationshipsTrust boundariesEvidence gapsTRANSFORMATIONHypothesisshapingIdentify plausible entry conditionsBound possible transitionsDefine consequential outcomesSpecify required proofBoundedhypothesesPrioritizedscenariosTest planClaim boundary
MAP-05

Inventory and Trace Workflow

Mapping progresses from intake through architecture capture and trace review to a reviewable security model.

Five-stage mapping workflow from intake through inventory, trace collection, relationship normalization, and review.

Scope and intakeSTEP 1Inventory componentsSTEP 2Collect traces andpolicySTEP 3NormalizerelationshipsSTEP 4Review readinessSTEP 5Workflow controlsScope boundary remains explicit • Every relationship retains sourcestate • Material changes trigger remapping