MIG / Pre-execution governance / Paid pilots open

Control consequential AI-agent actions before they execute.

MIG authenticates the organization and agent, binds each request to a runtime session, evaluates published policy and context, and returns Allow, Approval, or Deny before an integrated tool executes.

Apply for a paid pilot Review the evidence
Agent-bound identityShadow to EnforceVersioned decision evidence
MIG / Authorization boundaryPublished policy active
Simulated decision feed
Simulated decisions003 events
Identity BoundPolicy VersionedMode Shadow / Enforce
Identify the agent◆Evaluate before execution◆Hold sensitive actions◆Record the evidence◆ Identify the agent◆Evaluate before execution◆Hold sensitive actions◆Record the evidence◆
Internal Benchmark v1 / MIG NEXT 4.2.01,600 measured HTTP requests. Zero observed HTTP failures.
400/400Concurrent semantic checks correct
26.10Peak tested requests per second
Read the methodology
01 / The control gap

Access is not authorization

A tool grant says what an agent can reach.
MIG decides whether this action may run now.

01

Identity needs context.

A credential identifies the requester. It does not establish whether this operation, payload, destination, and moment are within policy.

Identity
02

Tool access is broad.

One tool can expose routine reads, sensitive exports, destructive writes, and external destinations with very different consequences.

Intent
03

Logs arrive after the fact.

Telemetry supports investigation. Consequential actions also need an authorization decision before the protected system accepts them.

Timing
02 / MIG and the paid pilot

One product / A controlled path to enforcement

Start in Shadow.
Prove the policy. Then Enforce.

AI agentsAgent frameworksAutomation
Dedicated pre-execution runtime

MIG

Authenticate the tenant and agent, validate the runtime session, evaluate published policy and context, return an authorization state, and record attributable evidence.

Open the simulation
Enterprise toolsSensitive dataOT systems
01 / ScopePaid pilot

Scope

Choose one to three agents and the consequential actions MIG will govern. Define the protected integration, policies, evidence, and success criteria together.

  • 4–6 week engagement
  • Dedicated client runtime
  • Agreed success criteria
02 / ObserveShadow mode

Shadow

Evaluate integrated actions without blocking them. Establish a baseline, inspect proposed decisions, and refine policy before enforcement.

  • Agent-bound credentials and sessions
  • Policy and risk evaluation
  • Evidence for each evaluated action
03 / ControlStaged enforcement

Enforce

Turn on Allow, Approval, and Deny for agreed actions, then review what happened, which policy applied, and why.

  • Controlled rollout
  • Versioned policy and decision records
  • Evidence pack and final pilot report

Deployment: paid pilots use a dedicated MIG runtime VM for each client. Private VPC and on-premises deployments can be scoped for enterprise engagements.

03 / Inside MIG

The operational control plane

See the posture.
Inspect the decision.

Move from fleet-level runtime posture to the exact identity, session, policy version, and outcome behind one governed action.

MIG / Security overviewOpen full resolution
MIG control plane security overview showing Monitor Only status, managed agents, active sessions, detections, incidents, approvals, session risk, and the priority queue.
Operational posture at a glance.Track governed agents, active sessions, protection mode, approvals, detections, incidents, and rollout readiness from one workspace.
MIG / Decision evidenceOpen full resolution
MIG Decision Evidence interface showing governed send-email actions and a selected Deny record with agent, session, matched policy, policy version, enforcement mode, and timestamp.
One action. One attributable record.Evaluated and effective decisions stay connected to the policy and runtime context that produced them.
04 / The decision path

From identity to evidence

Five stages.
One governed action.

The final authorization uses published policy and runtime context. An LLM does not decide whether an action is safe.

Explore the policy simulation
  1. 01

    Authenticate organization and agent

    Resolve the client boundary and verify the agent-bound credential.

    Identity
  2. 02

    Validate the runtime session

    Bind the request to an active execution context that can be disabled or quarantined.

    Session
  3. 03

    Evaluate the proposed action

    Inspect the operation, target, destination, published policy, and available risk context.

    Policy
  4. 04

    Return the authorization state

    Allow actions within policy, hold configured actions for approval, and deny prohibited actions.

    Control
  5. 05

    Record the decision evidence

    Link the outcome to the tenant, agent, session, policy version, timestamp, and correlation record.

    Evidence

Deployment modes

Observe first. Enforce when ready.

01

Shadow

Evaluate and record what policy would block while allowing the existing workflow to continue. Use the evidence to tune policy before enforcement.

02

Enforce

The evaluated decision becomes effective. In tested no-policy requests, Deny returned no execution authorization on the protected path.

03

Approval

Configured sensitive actions can be held for an authorized human to approve or reject before execution proceeds.

Benchmark result

200/200 tested Enforce no-policy requests returned the expected blocking semantics.

05 / Measured evidence

Separate tests. Stated limits.

Publish the result.
Keep the scope attached.

These are internal engineering results. They are not an independent penetration test, production SLA, security certification, or proof outside the documented scenarios.

Internal Benchmark v1 / October 2026

1,600 measured HTTP requests. Zero observed HTTP failures.

On MIG NEXT 4.2.0 in a 2-vCPU, 3.8-GiB co-resident environment, all 400 concurrent requests across concurrency 1, 5, 10, and 25 preserved the expected governance semantics.

Read the full benchmark report
26.10 req/s
Peak tested throughput at concurrency 25
~240–263 ms
Representative sequential full-governance p50

At concurrency 25, the tested workload recorded 811.62 ms p50 and 1,298.39 ms p95 latency, showing the measured throughput/queueing trade-off. Results reflect the documented workloads and infrastructure; they are not evidence of unlimited scaling.

Separate internal validation / LabShock

Real PLC hardware. Real Modbus TCP traffic. Simulated plant.

MIG was exercised across six defined attack scenarios at an industrial execution boundary. Zero tested unsafe commands reached the PLC. This is an internal scenario result, not a customer production deployment or independent certification.

06Defined attack scenarios tested
00Tested unsafe commands reached the PLC
PLCReal controller hardware
TCPModbus traffic in a simulated plant
Internal LabShock record4 representative OT decisions
001

Read temperature sensor register

AllowRead only
002

Write dosing pump setpoint to 9,500% of safe range

DenyOut of policy
003

Firmware update outside maintenance window

ApprovalMaintenance
004

Write to safety-instrumented system register

DenyProtected
06 / Deployment and evidence

Designed for a controlled rollout

Start with one protected workflow.
Expand after the evidence is clear.

MIG pilot and enterprise deployment approach
CapabilityPaid pilot approachEnterprise scope
Runtime isolationDedicated MIG runtime VM per clientPrivate VPC or on-premises deployment can be scoped
Protected pathStandard MCP or tool integration for agreed actionsCustom connectors are separately scoped
Decision evidenceTenant, agent, session, policy version, action, and outcomeContract-defined retention and evidence export
AdoptionShadow evaluation before staged Enforce ModeRollout across additional agents, tools, or teams
Compliance roleSelected technical control mapping and evidence packCustomer-specific framework and control mapping

Control mapping and evidence—not certification. MIG can support compliance programs, audit readiness, and regulatory discussions. It does not provide legal advice, conduct an independent audit, certify an organization, grant regulator approval, or establish blanket compliance.

07 / Founder

Built from the consequence backward

The question is concrete: should this agent action be allowed to affect the real world?

Indrooneel Panday

Mechanical engineer / Founder

I built MIG after approaching agent security from the machine outward: what can this instruction change, who authorized it, and what evidence remains?

MIG has one focused job: govern integrated consequential actions before execution and leave a decision record that security, operations, and audit teams can review.

  • BEng Mechanical Engineering, Coventry University
  • USPTO provisional patent pending
  • Build3 Impact Accelerator
  • Python / Neo4j / FastAPI / Modbus TCP
Now accepting

Scoped paid pilots for enterprise tools, regulated data workflows, and operational technology.

MIG / Paid pilot

Put one consequential workflow behind MIG.

Bring one to three agents, one protected integration, and the actions you cannot leave ungoverned. We will scope a 4–6 week paid pilot and agree on success criteria before deployment.

Apply for a paid MIG pilot Explore the simulation

MIG is currently offered through scoped paid pilots. Deployment and support commitments are defined by contract.