For Microsoft · Foundry Agent Service · Copilot Studio · Agent Framework · Entra Agent ID

Every Foundry and Copilot agent action,
independently judged before it executes.

Three agent actions below are shaped exactly as they leave the Microsoft agent stack — an agent flow in Copilot Studio, a function invoked from the Agent Framework, an MCP tool reached through Foundry Agent Service — and each one goes through the live Veridect system on this page. On your side the integration is one HTTP step, one filter class, or a URL change behind the AI gateway. Behind it is the whole control plane: consensus from frontier models across independent vendors, deterministic policy classes, risk routing, a hash-chained ledger, and an Ed25519-signed decision record you can verify right here.

Open the full live tour
3 seams
an agent-flow step, a function filter, or one MCP URL — your agents, connectors and models stay exactly as they are
1 judgment
POST /pre-action — behind every path (the MCP gateway makes that call for you); the answer is a verdict plus a signed record
1 record each
every decision — pass, hold or refusal — is a signed record, exportable as newline-delimited JSON into the SIEM or GRC pipeline you already run
0 trust required
every decision re-derives from its recorded inputs and verifies against a published key — try it below
Where it sits

Between the agent’s plan and the action.

Microsoft runs the agent: Foundry Agent Service hosts and orchestrates it with tools over MCP and OpenAPI; Copilot Studio builds agents for the business with connectors and agent flows; the Agent Framework carries them in code; Entra Agent ID gives each agent an identity, with Purview and Defender watching data and threats. Veridect sits at the one moment none of those were built to own: the instant before an action with consequences executes — a case reassigned, a permission granted, a payment released — when an independent judgment — not the model that proposed the action, not the platform that hosts it — decides whether it goes, waits for a person, or never happens, and signs the record either way.

Your agent on Microsoft

Proposes an action

  • Copilot Studio agents running agent flows and connector actions
  • Agent Framework and Semantic Kernel code calling any function or plugin
  • Foundry agents reaching tools over MCP through the AI gateway in Azure API Management
Veridect · live control plane

Judges it before it runs

  • Deterministic scope check against the agent’s configured authority
  • Policy classes in code — money thresholds, protected data, regulated data, cumulative exposure
  • Multi-vendor model consensus with calibrated confidence and a dissent register
  • Risk routing: greenlight, escalate to a named human queue, or block
  • Hash-chained, Ed25519-signed record — written whether it passes or not
Outcome

Three doors, one record

greenlightthe flow step, the function or the tool runs; the verdict and record id travel with it
escalateheld for a person in the queue the policy names — the flow notifies, the function returns the verdict, the tool call waits
blocknever executes — and the refusal is on the ledger too
Three thin paths

The integration is thin. The system behind it is not.

Each path maps the call your agent was already making onto one judgment — POST /api/ai/consensus/pre-action, made by your flow step, your filter, or the MCP gateway on your behalf: the verb, the target object, the fields, which agent is asking, and what that agent is authorized to do. Nothing about the agent, the model, or the connector changes. The verdict decides whether the original action proceeds.

PATH 01 · COPILOT STUDIO · AGENT FLOW

One HTTP step before the action step

Copilot Studio agents act through agent flows and connectors. Add one HTTP action as the first step of any flow that writes, pays, grants or sends: it posts the action to Veridect, and a condition lets the work step run only when the verdict is greenlight. The flow’s own run history then shows the verdict and the record id for every action — the agent sees why, and so does the ledger.

2 steps · one HTTP action + one condition · no code

Fail-closed by construction: a failed, timed-out or malformed HTTP step never satisfies the condition, so the work step does not run. The key, the agent id and the agent’s authority are environment variables or a connection reference — set when the flow is built, never trigger inputs the agent fills in; the key never sits in the flow. The same two steps fit a Power Automate flow called from a Microsoft 365 Copilot or Dynamics 365 agent.

# agent flow — "Veridect pre-action" is step 1; the work step runs only on greenlight
steps:
  - name: Veridect pre-action                       # HTTP action
    method: POST
    uri: https://<your-veridect-host>/api/ai/consensus/pre-action
    headers: { Authorization: "Bearer @{parameters('veridect_key')}", Content-Type: application/json }
    body:
      action:            "@{triggerBody()?['action']}"          # e.g. "reassign_case"
      target:            "dynamics365:@{triggerBody()?['entity']}"
      parameters:        "@{triggerBody()?['fields']}"
      callingAgent:      "@{parameters('agent_id')}"              # environment variable: the Entra Agent ID this flow belongs to — set by the maker, not an input
      callingAgentScope: "@{parameters('agent_scope')}"           # environment variable: its configured authority, in words — never a trigger input
    timeout: PT60S

  - name: Condition — proceed?
    expression: "@equals(body('Veridect_pre-action')?['verdict'], 'greenlight')"   # a failed step never reaches 'true'
    if_yes:
      - Update a row (Dataverse)                      # the work step — the record id goes into the note
    if_no:
      - Respond to the agent:
          "Not executed — Veridect @{body('Veridect_pre-action')?['verdict']} · record @{body('Veridect_pre-action')?['auditBundleId']}"
PATH 02 · AGENT FRAMEWORK · FUNCTION FILTER

One filter, every function the agent can call

Agents built on the Agent Framework or Semantic Kernel call tools as functions. Register one function-invocation filter: it posts the function name and arguments to Veridect and lets the function body run only on a greenlight, otherwise returning the verdict and the record id as the function’s result. Every plugin, every function, every agent that shares the kernel is covered; nothing in the agent or its prompts changes.

~30 lines · one filter class · humans untouched

Where the authority lives: the scope string is the agent’s configured authority, kept with the agent’s definition. A read-only knowledge agent that proposes a permission grant is a categorical no-authority action — the deterministic layer blocks it before any model is asked to weigh in. Watch it below. The policy classes work over field names; send values only for the fields your policy needs.

// Semantic Kernel function-invocation filter — one in front of every function the agent can call (Agent Framework's function middleware takes the same shape)
public sealed class VeridectFilter(HttpClient http, string agentId, string agentScope) : IFunctionInvocationFilter   // agentId + agentScope come from the agent's registration, never from the model
{
    public async Task OnFunctionInvocationAsync(FunctionInvocationContext ctx, Func<FunctionInvocationContext, Task> next)
    {
        var body = new {
            action            = ctx.Function.Name,                        // e.g. "release_vendor_payment"
            target            = "dynamics365_finance:" + ctx.Function.PluginName,
            parameters        = ctx.Arguments,
            callingAgent      = agentId,                                  // the agent's Entra Agent ID
            callingAgentScope = agentScope                                // its configured authority, in words
        };
        string verdict = "unavailable", recordId = "";                   // closed until proven open
        try {
            using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(60));
            var r = await http.PostAsJsonAsync("/api/ai/consensus/pre-action", body, cts.Token);
            if (r.IsSuccessStatusCode) {
                var d = await r.Content.ReadFromJsonAsync<JsonElement>(cts.Token);
                verdict  = d.TryGetProperty("verdict", out var v)        ? v.GetString()  ?? "unavailable" : "unavailable";
                recordId = d.TryGetProperty("auditBundleId", out var id) ? id.GetString() ?? "" : "";
            }
        } catch { /* network, timeout, parse: all stay closed */ }

        if (verdict != "greenlight") {
            ctx.Result = new FunctionResult(ctx.Function, $"Not executed — Veridect {verdict} (record {recordId})");
            return;                                                        // the function body never runs
        }
        await next(ctx);                                                   // the work, with the record id in scope
    }
}
// kernel.FunctionInvocationFilters.Add(new VeridectFilter(http, agentId, agentScope));
PATH 03 · FOUNDRY AGENT SERVICE · MCP THROUGH THE AI GATEWAY

One MCP URL behind the gateway

Foundry agents reach tools over MCP, usually through the AI gateway in Azure API Management. Register the real tool server as a Veridect upstream once and point the gateway’s backend — or the agent’s MCP tool definition — at Veridect instead. Every tools/call is judged in flight; tools/list, initialize and everything else pass straight through. A refused call is never forwarded.

0 lines of agent code · one registration, one URL

Identity on the wire: the agent’s identity, workflow id and business context ride in params._meta["veridect/…"] — unsigned, that is the caller’s own claim, and the decision record marks it as such; a tenant can require a signed Ed25519 identity envelope on every call, and an unsigned call is then refused inside the protocol. Both outcomes run live below. The gateway’s own policies — authentication, rate limits, logging — keep working in front.

# 1) once — register the real tool server as an upstream (admin call)
POST /api/ai/consensus/mcp/upstreams/{tenant}
{ "upstreamId": "foundry-tools-prod", "url": "https://<your-tool-server>/mcp", "enabled": true }

# 2) the one change — the backend behind the AI gateway (or the agent's MCP tool URL)
before:  https://<your-tool-server>/mcp
after:   https://<your-veridect-host>/api/mcp/gateway/foundry-tools-prod

# Foundry agent — the MCP tool definition, unchanged except for the URL
{ "type": "mcp", "server_label": "tools",
  "server_url": "https://<your-veridect-host>/api/mcp/gateway/foundry-tools-prod",
  "headers": { "Authorization": "Bearer <VERIDECT_API_KEY>",                # your Veridect tenant
               "X-Upstream-Authorization": "Bearer <tool-server token>" } }  # forwarded to the tool server

# 3) what the agent sees on a greenlight: the upstream's own result, plus
#    result._meta["veridect/verdict"] and result._meta["veridect/bundleId"]
#    on escalate / block: a JSON-RPC error (-32003 / -32004) carrying the
#    verdict and the record id — and the tool server never receives the call.
Run it live

Four Microsoft-shaped actions, through the live system, now.

Each card sends the exact request the agent flow, the function filter, or the gateway MCP connection would send, to the live Veridect system on a shared sandbox tenant. The verdicts are real multi-model decisions made while you wait; the records are written to the ledger and signed; the Verify button re-derives the verdict from the recorded inputs and checks the signature against the published key. Expected outcomes are stated in advance — the engine decides.

Ready. Each decision takes a few seconds while the model roster deliberates.
LIVE 01 · PATH 01 · COPILOT STUDIO AGENT FLOW

Reassign a Dynamics 365 case to the product-support queue

A Copilot Studio service-desk agent runs its reassign_case flow on CAS-04471 with a note. Its configured authority: “may read cases and may categorize, prioritize and reassign them to the correct queue.”

Expected: greenlight — inside authority, no policy class fires, the roster agrees. The condition is true, the Dataverse update step runs, and the record id rides along in the note.

Waiting. Request shape: the agent flow’s HTTP step body, verbatim.
LIVE 02 · PATH 01 · COPILOT STUDIO AGENT FLOW

A read-only knowledge agent tries to change site permissions

A Copilot Studio knowledge agent proposes update_site_permissions: Edit on the Finance Policies SharePoint site for an external partner account. Its configured authority: “read-only: may search SharePoint knowledge sources to answer questions.”

Expected: block — a read-only agent proposing a permission change is a categorical no-authority action; the deterministic scope check decides, the models are consulted for the record, and the flow responds with the verdict instead of granting.

Waiting. Request shape: the agent flow’s HTTP step body, verbatim.
LIVE 03 · PATH 02 · FUNCTION FILTER

Release a $48,000 payment to an approved vendor

A Foundry accounts-payable agent, inside its authority (“may read invoices and may release payments to approved vendors”), calls release_vendor_payment for an amount above this tenant’s policy limit of $10,000.

Expected: escalate — the deterministic dollar_threshold policy class fires and routes the action to the queue the policy names. Authorized but consequential actions escalate to a person; they are never silently blocked and never silently allowed.

Waiting. Request shape: the filter’s request body, verbatim.
LIVE 04 · PATH 03 · FOUNDRY → MCP

The same tools/call, two tenants, two outcomes

A JSON-RPC tools/call for lookup_policy_limit goes through the live Veridect MCP gateway to a sample tool server that counts what it actually receives. First on the shared sandbox tenant; then on a tenant that requires a signed identity envelope, sent without one.

Expected: first call forwarded, the tool’s own hit counter goes up by one and the result carries _meta["veridect/bundleId"]; second call refused inside the protocol (-32004 identity_not_presented), counter unchanged, refusal on the ledger.

Waiting. Request shape: JSON-RPC 2.0, verbatim.

What on this page is live, and what is illustrative

Live: every verdict, confidence, dissent register, policy class, escalation route, ledger write, hash chain, Ed25519 signature, MCP forwarding decision and verification result above comes from the production Veridect system on a shared sandbox tenant — the same endpoints an integrator calls. The consensus roster is four frontier providers from independent vendors with a decisive-verdict early stop, so a decision on this surface typically records three; the models are named in each record’s dissent register. The $10,000 escalation limit is this sandbox tenant’s policy; in your tenant every threshold is yours.

Illustrative: the agent side. No Copilot Studio flow, Foundry agent or Agent Framework process executes from this page; each card sends the exact request the flow step, the filter or the gateway MCP connection would send, so what you watch is the decision those integrations would receive. The MCP calls in Live 04 leave this browser as a standard MCP client; a Foundry agent’s MCP tool connection and the Azure API Management AI gateway were not exercised here. The code above is written against the documented Semantic Kernel filter contract (IFunctionInvocationFilter), the Power Automate expression language that agent flows share, and the Foundry MCP tool definition; the tool-server URL is a placeholder for your own. The integration is demonstrated wiring, not a certified, listed or endorsed Microsoft solution.

Verification proves that the enforcement decision re-derives from the recorded inputs and that the record is unmodified and signed by the published key. It does not re-run the models: the consensus summary is attested through the recorded dissent register and verifier-text hash, and disclosed as such in the proof itself.

Microsoft, Azure, Copilot, Microsoft 365, Dynamics 365, SharePoint, Microsoft Entra, Power Automate and other Microsoft marks are trademarks of the Microsoft group of companies. Veridect is an independent company and is not affiliated with or endorsed by Microsoft.

Five questions, answered for a Microsoft team

The short version.

How does this help?

It lets Foundry and Copilot agents into the workflows that carry consequences — payments, permissions, customer and employee records, regulators — because an independent judgment stands in front of each action and a signed record stands behind it. The model that proposes the action is never the one that approves it.

How do I integrate it?

One of the three paths above: an HTTP step in the agent flow, a filter on the kernel, or one MCP URL behind the gateway. Your agents, connectors and models stay as they are. It runs where you say, on your keys, with the agent’s Entra Agent ID carried as the calling identity.

How long does it take?

The system is live today. A private sandbox on your own policy thresholds in a day once you say go; production typically about two weeks, with the pace set mostly on your side — security review, keys, access. Ours is ready on day one.

How does this make money?

Three levers, none of them invented here: revenue held back because agents could not be trusted with the consequential step; cost stopped on human review of actions a signed record now settles; losses not taken on the actions that should never have executed. Your own number comes out of the sandbox.

Why you and not a big well-known company?

Because the judgment has to be independent of the model and of the platform to be worth anything to an auditor. Entra Agent ID, Purview and Defender are the platform’s own view of its agents; a platform grading its own agents is self-governance. Veridect is a separate control plane with its own ledger and keys, validated by an external red team on scope-violation semantics, and verifiable offline. Try to forge a record on the live tour; the engine refuses it.

Test-drive it yourself.

Run the four actions above, verify the records, then take the full live tour — identity envelopes, delegation chains, cross-agent exposure, the fleet layer, and the forgery the engine refuses. Seven minutes, open access.

Prefer to see it on your own scenarios? Paste one on the pre-action console — or write to lrussell@veridect.ai and a scoped production sandbox on your own thresholds and your own tenant follows in a day.

The same control plane, built the same way for Snowflake, AWS, ServiceNow, CrowdStrike, Rubrik, Salesforce, Databricks, Okta and Google Cloud — one engine behind all ten pages, each run live. All ten platforms →