Defend · Harden · Verify
Defend
Change the controls that break the attack path.
Turn mapped risks and reproduced failures into enforceable architecture changes, permissions, guardrails, release gates, telemetry, rollback paths, and regression tests.
Defend turns security evidence into changed system behavior. We redesign trust boundaries, constrain agent and tool authority, define gateway and guardrail policy, add detection and approval logic, and turn failures into regression conditions. Attack Path Analysis chokepoint analysis identifies the controls that disrupt the most supported attack paths so teams can fix for defensive leverage, not just ticket severity.
Defense completion
A finding is not fixed because the ticket closed.
A defense is complete when the system behavior changed, the expected control is explicit, the original failure has a retest condition, and evidence shows whether the path still succeeds.
Fix the shared weakness, not every symptom.
Several attack paths can depend on the same overbroad permission, missing approval, unsafe action scope, or weak trust boundary.
Interrupt the Paths
The highest-value control is often the chokepoint that disrupts several plausible attack paths at once.
Several attack paths converging on a shared weakness, followed by a selected control, blocked paths, and visible residual risk.
The highest-leverage control is often the chokepoint that interrupts several grounded paths at once, reducing risk without adding a separate control for every observed symptom.
Capabilities
Turn findings into controls that hold.
Attack-path chokepoint analysis
Rank controls by how many meaningful attack paths they disrupt. Attack Path Analysis exposes shared weaknesses across paths so one well-placed control can eliminate multiple failure paths.
Architecture and trust-boundary changes
Change where data, identities, models, retrieval layers, agents, tools, and external systems are allowed to interact.
Agent and tool authority
Reduce blast radius with scoped identities, least privilege, credential boundaries, explicit tool policy, approval gates, and constrained external effects.
Runtime policy and telemetry
Define model and provider policy, logging, sensitive-data handling, tool-call controls, decision telemetry, fallback behavior, and runtime enforcement.
Guardrails, evals, and regression criteria
Turn vague safety or security goals into explicit blocked behaviors, test fixtures, thresholds, degradation rules, release criteria, and repeatable regression tests.
Approval, rollback, and kill-switch design
Define where humans must intervene, what context they need, how actions are reversed, and how unsafe automated behavior is stopped.
Workbench capabilities that support Defend
Control the path, not just the ticket.
Authority Graph
Model agent, identity, credential, tool, MCP, approval, and external-action authority, then turn dangerous compositions into least-privilege controls, approval requirements, and hardening tasks.
Attack Path Analysis chokepoint analysis
Rank controls by how many supported attack paths they break so remediation targets the weakest shared dependencies first.
Runtime Trace
Capture and replay prompts, retrieval context, model calls, tool calls, approvals, outputs, and policy decisions so teams can verify control behavior and preserve retest evidence.
Model Gateway
Centralize supported model/provider routing, policy enforcement, logging, sensitive-data handling, fallback behavior, spend controls, and other boundary decisions.
AI Guardrails & Evals Review
Validate guardrails, eval criteria, blocked behaviors, regression coverage, and release criteria against real failure conditions.
RAG Security Testing
Use retrieval-authorization findings to define identity, boundary, and retest fixtures that support hardening work.
AI Security Program Baseline
The baseline identifies program-level ownership and control gaps. Defend is where technical controls are designed, implemented, and verified.
Code Scanner
Carry AI-native code findings into control-gap analysis and hardening work when upstream evidence is needed.
Closure requires replayable proof.
Remediation is complete only after the control is implemented, the original behavior is retested, and the remaining risk is recorded honestly.
Fix, Retest, Prove
A remediation is not complete until the control change is retested and the resulting evidence closes or updates the finding.
Governed remediation lifecycle from accepted finding through control implementation, retest, decision gate, closure, residual risk, or rework.
- 1Accept the findingConfirm scope, consequence, owner, and evidence state.
- 2Design the controlChoose the least disruptive change that addresses the supported path.
- 3Implement and instrumentChange the system and preserve the evidence needed to retest it.
- 4Retest the pathReplay the relevant conditions, alternatives, and expected controls.
- Closed
- Residual risk
- Control failed
- Inconclusive
The result may be closed, partially mitigated, failed, or inconclusive. Evidence—not ticket state—determines which conclusion is supportable.
Adjacent resources
Program baseline that supports Defend.
Use the Program Scorecard to baseline control gaps, ownership, and roadmap before or after hardening work.
AI Security Program Baseline
The baseline identifies program-level ownership and control gaps. Defend is where technical controls are designed, implemented, and verified.
MAP
Inventory & Trace
Understand architecture, data paths, trust boundaries, authority, ownership, and evidence gaps.
Open routeATTACK
Test & Validate
Reproduce AI abuse paths and determine which findings form meaningful attack paths.
Open routeDEFEND
Harden & Verify
Change architecture and controls, constrain authority, and verify the original paths no longer succeed.
Open routeEVIDENCE
Prove & Reuse
Preserve findings, attack paths, fixes, retests, control proof, and buyer-ready artifacts.
Open route