This page is the proof layer for DiaCroma for Agents: inspectable reference artifacts, controlled replays and dated platform runs. It does not turn a demonstration into a customer result, or a live connector into a closed execution route.
What you can inspect now
Acme is our demo company. We invented the business; the deployment is real — its own tenant, its own network, its own signed record. The floor shows the actions agents propose, what DiaCroma decides, and the trajectory piling up. It proves the mechanics are inspectable. It is not a customer result.
Inspect the reference floor →Replays 204 recorded turns from 13 models. The benchmark and transcripts are external; the DiaCroma policy, replay and interpretation are ours.
Inspect models, turns and verdicts →Shows policy extraction, supporting sentences, a second-model check and the questions returned to human authority when the source leaves a gap.
Inspect the onboarding record →The end-to-end record: signed authority → proposal → decision → permit → receipt → settlement and replay. A proposal and verdict alone are decision evidence, not proof of the resulting business effect.
For the category and problem, start at Where we fit →. For architecture and deployment, read Product →. The agent-drift explainer (PDF) → is explanatory, not runtime evidence.
Platform evidence
The table holds only what we have actually run. What we intend to run next is below it. Full governance also requires the enterprise to close any alternate route to the same effect.
Status describes the evidence held by DiaCroma, not the vendor’s full platform capability or a vendor endorsement. Checked in August 2026.
| Platform | Integration seam | What we have seen | Current claim |
|---|---|---|---|
| Microsoft Copilot StudioMicrosoft tenant | MCP server URL + header credential | Live in a Microsoft tenant. The tool registers, and the controls that close the route are there. We have not yet watched it block a real call. | SEAM LIVE · BLOCK NOT WITNESSED Coverage requires alternate connector and custom routes to be closed. |
| Microsoft Foundry Agent ServiceFoundry project | MCP server URL + multiple headers | Live in a Foundry project. We saw no endpoint allowlist there, so an agent could still reach the same tool another way. | SEAM LIVE · BYPASSABLE The boundary can brake; the surrounding estate must close other routes for full governance. |
| Your own codeCustom agents and frameworks | SDK or HTTP call | You can call it today. How much it covers depends on whether your setup pushes agents through it. | INTEGRABLE · ROUTE DEPENDENT |
Coming next. What we intend to do — not a schedule. None of these has been run in a real account; that is why they are here and not in the table above. When one goes live, it moves up.
Route agents through its published MCP gateway in a real AWS account, then test whether the same tool can still be reached another way.
Confirm how it signs in and how it runs in a real org, then govern one route end to end.
Choose the seam, then put one governed route through it, from proposal to signed record.
Reachable is not inevitable. If an agent can call the same business tool through another route, DiaCroma reports partial, unknown or unmanaged coverage. Closing that route is an enterprise control, not a DiaCroma marketing claim.
Claim boundaries
It demonstrates mechanics. It does not establish customer adoption, measured savings or ROI.
DiaCroma’s policy, replay and interpretation have not been independently validated.
Enforcement depends on credentials and alternate execution paths being placed behind the boundary.
The records support review and defensibility; they are not a legal opinion or certification.
Produce your own evidence
Choose one agent, one business effect and one execution path. Validate the full record, then test whether the route can be bypassed.
