01 · Assess
Test the agreed surface.
We work within written authorization to examine prompts, retrieval, agents, tool and action paths, and defined configuration or supply-chain boundaries.
AI security · broad regulated enterprise
Adversarial AI assurance, with the limits in plain sight.
We help teams test the AI surfaces that can move data or take action, turn agreed findings into defensive controls, and re-test the work that changed. The result is a clearer technical risk decision, not a bigger promise.
A DSE engagement is a point-in-time technical assessment under a written statement of work. It is not a certification, compliance audit, continuous monitoring service, or 24/7 SOC.
One accountable path
Testing without hardening leaves risk open. Hardening without testing leaves it assumed.
Adversarial assessment and defensive engineering are useful together. We keep them distinct, connect them through the findings, and leave each approval decision with the people accountable for the system.
The evidence loop
Assess. Harden. Re-test.
A scoped assessment produces a useful decision only when a team can trace the path from the scenario tested, to the control selected, to the evidence checked after remediation.
02 · Harden
Turn findings into controls.
We help your team prioritize technical fixes and document its own risk and approval decisions. The customer retains responsibility for accepting risk and authorizing change. See how an authorized red-team finding becomes a blue-team control decision.
03 · Re-test
Check what changed.
For agreed findings, we re-check the changed behavior or configuration and record the result. A re-test is evidence for the scoped item, not a guarantee about the whole system.
Track one
Authorized red-team assessments.
We assess the ways an AI application can be persuaded, confused, over-privileged, or induced to expose information. Every engagement is limited to the systems, scenarios, and testing window named in the statement of work.
Application behavior
LLM and agent attack paths.
Explore agreed prompt-injection, retrieval-isolation, tool-abuse, data-exposure, and loop-bound scenarios in the interfaces your team operates.
Explore LLM security testing →Decision-ready output
Findings that can be acted on.
Receive a point-in-time finding log, severity and context, a prioritized remediation path, and an agreed re-test option. Framework references inform the work; no single engagement covers every category.
See the AI security assessment →Scope boundary
Testing is not permission to overreach.
We test only what the customer is authorized to have tested. This is not an implied network penetration test, social-engineering engagement, managed detection service, or standing authorization to operate against third-party systems. Those needs require their own scope and written approval.
Track two
Defensive control engineering.
The defensive track focuses on the configuration and definition surfaces around AI tools. It helps teams make their own approvals visible, reviewable, and harder to change silently.
MCP configuration governance
Know the surface your agents can reach.
Build and maintain an internal inventory of tool surfaces, configurations, and integration points. DSE can support the process; the customer owns every approval decision.
See mcp-warden capabilities and limits →Definition integrity
Pin what was reviewed. Surface drift.
mcp-warden is DSE's open-source definition-integrity control. Its pin and check workflows can help capture an approved MCP definition and make a CI pipeline answer when that declared surface changes.
Review the open-source project ↗Control boundary
One layer, not the whole defense.
mcp-warden is a definition-integrity control with distinct static, capture, and optional result-inspection modes. It does not replace a static tool-poisoning scanner, a full runtime gateway, vendor assessment, incident response, or a complete AI security program. It does not issue a certification or decide whether a customer should approve a tool.
Public research
A one-time view of published configuration patterns.
Our published MCP configuration research was a static, aggregate analysis of files already made public by their owners. No repository is named, no credential was tested, and the research describes a bounded public corpus.
Public configurations are not representative of private enterprise deployments. The findings are not an industry baseline, a customer assessment, or an ongoing monitoring commitment.
Read the method and findings →Straight answers
What the work is, and is not.
Clear scope makes the technical findings more useful to security, engineering, risk, and counsel teams.
Is this a compliance audit or certification?
No. DSE provides a point-in-time technical assessment and advisory work. Framework references can inform the scope, but the engagement is not a compliance audit, regulatory attestation, or certification.
Does this replace continuous monitoring or a SOC?
No. The work is not continuous monitoring and DSE does not operate a 24/7 SOC. We can help a team define controls and evaluate evidence around a scoped AI surface.
Who approves tools and accepts risk?
The customer does. We can help document the technical surface and the decision context, but approval authority and accountability remain with the customer.
Does mcp-warden secure an agent at runtime?
Its optional guard proxy can inspect tool results at runtime, but mcp-warden is not a full runtime gateway or agent firewall. It does not decide whether a never-before-seen tool definition is benign.
Start with the system in front of you
Make the next AI risk decision evidence-led.
Bring the architecture, the concern, or the change you are about to ship. We will help define a scope that is technically useful and honest about what it can prove.
Scope a conversation →