MIDAS

Authority governance engine for autonomous decisions.

MIDAS determines whether an automated agent is within authority to perform a consequential action. Every evaluation produces exactly one outcome and one tamper-evident audit envelope — capturing what was requested, what authority was resolved, and why the outcome was reached.

Current release candidate: v1.1.0-rc.1 — intended for evaluation while MIDAS is under active development. The runtime governance contract (/v1/evaluate), envelope shape, audit-chain integrity, FailModePolicy resolution, and control-plane apply path are the stable surfaces; Explorer graph UI surfaces remain in active iteration. The v1.0.x tags are historical early releases.

---

Intended users and regulatory context

MIDAS is intended for organisations that need governed, auditable control over autonomous or agentic decision-making. This is especially relevant in highly regulated sectors such as banking, insurance, pharmaceuticals, healthcare, public services, critical infrastructure, and other environments where automated decisions must be explainable, bounded, reviewable, and evidenced.

The project is designed to support organisations that need to demonstrate runtime controls over AI-enabled or agentic systems. MIDAS does this by turning delegated authority into deterministic runtime checks, recording evidence for each governed decision, supporting human escalation paths, and emitting auditable events for downstream review and monitoring.

MIDAS' purpose is to provide technical governance capabilities that can help organisations implement and evidence controls expected by emerging AI governance regimes. These include risk-based regulation, auditability, human oversight, traceability, operational monitoring, and accountability.

Examples of relevant governance and regulatory contexts include the EU AI Act, which sets risk-based obligations for AI developers and deployers and includes requirements for areas such as risk management, technical documentation, logging, transparency, and human oversight for high-risk systems; and Singapore’s Model AI Governance Framework for Agentic AI, which provides guidance for deploying agents responsibly and emphasises continued human accountability.

In practical terms, MIDAS is intended to help organisations answer operational governance questions such as:

• Which agent or automated service is making this decision?
• What authority has been granted to that agent?
• Which decision surface is being used?
• What confidence, consequence, and context were submitted?
• Was the decision accepted, escalated, rejected, or sent back for clarification?
• What evidence was recorded?
• Can the decision be audited after the fact?
• Can downstream governance, monitoring, and review processes consume events from the decision?

How MIDAS Is Used

MIDAS is used at the point where an agent, automation, or AI-enabled service is about to make or recommend a consequential decision.

The agent does not ask MIDAS to make the business decision. Instead, the agent calls MIDAS to check whether the proposed decision is within delegated authority. The agent submits a request to /v1/evaluate with:

• the decision surface being used;
• the agent identity;
• the process context;
• the confidence score;
• the consequence being proposed;
• any required decision context;
• a request source and request ID for idempotency.

MIDAS then resolves the applicable authority chain:

Decision Surface → Authority Profile → Grant → Agent

The evaluation is deterministic and independent of any LLM provider, prompt, or orchestration framework. The agent may use an LLM, a rules engine, a workflow engine, or conventional application logic to propose an action. MIDAS evaluates that proposed action against explicit authority structures and returns one governed outcome:

Outcome	Meaning
accept	The proposed decision is within delegated authority and may proceed.
escalate	The decision requires review because confidence, consequence, policy, or context exceeds the granted boundary.
reject	The decision is not permitted.
request_clarification	Required context is missing or insufficient.

Every evaluation records a tamper-evident evidence envelope and appends a transactional outbox event for downstream processing. This allows MIDAS to act as a deterministic runtime control point for autonomous decisions while preserving an auditable record of what was requested, what authority was resolved, and why the outcome was reached.

Product Preview

Explore the live MIDAS demo environment:

https://midas.accept.io/explorer

MIDAS includes a graph-native Explorer for visualising runtime governance, authority delegation, operational context, evidence, drift, and decision topology.

Authority Graph: governed decision surfaces, authority relationships, fail-mode visibility, and runtime governance topology.

Context Graph: operational relationships, evidence flow, governance signals, and runtime context topology.

Current platform status

MIDAS now provides a governed runtime path for evaluating agentic decisions through /v1/evaluate. The runtime persists operational envelopes, tamper-evident audit events, transactional outbox intent, and idempotency state in Postgres before returning governed success.

The repository includes the core evidence needed for controlled pilot and recoverable production evaluation: runtime metrics, class-aware failure semantics, audit_status on governed success, FailModePolicy governance, Prometheus alert rules, a Grafana dashboard, incident drill checklists, Docker/Postgres backup and restore verification, a p999-capable sustained-load harness, and Docker/Postgres outbox dispatcher validation.

This supports MIDAS readiness Level 1 and repository-level Level 2 evidence for a single-node Docker/Postgres recoverable-inline deployment shape, where authentication, persistent storage, monitoring, backup/restore, and operational ownership are in place.

MIDAS does not currently claim Bank Tier 1 inline readiness. It does not yet prove active-active resilience, RPO/RTO targets, multi-replica shared-Postgres scaling, production p999 SLOs, or payments-inline suitability. Higher readiness levels require additional deployment-specific validation.

See:

• Runtime Readiness Level Model
• Runtime readiness guide
• Performance guide
• Backup and restore guide
• Observability assets

---

Explorer

Explorer is MIDAS’s graph-native visibility surface for runtime governance. It is intended to be used in governed environments to inspect authority, context, evidence, drift, and decision topology.

An interactive local sandbox is available at:

http://localhost:8080/explorer

Open it in a browser. Demo scenarios are pre-loaded and ready to run. Sign in with demo / demo in default local mode.

For production use, Explorer should be deployed only with appropriate authentication, configured data stores, intentional demo-data settings, and environment controls. Do not expose an unauthenticated local/demo Explorer instance publicly.

---

Quick Start

Docker (recommended)

docker compose up --build

Then open http://localhost:8080/explorer and sign in with demo / demo.

No database required. MIDAS starts with an in-memory store and demo data pre-loaded.

Run without demo mode:

Bash/sh:

MIDAS_DEV_SEED_DEMO_DATA=false MIDAS_DEV_SEED_DEMO_USER=false docker compose up --build

PowerShell:

$env:MIDAS_DEV_SEED_DEMO_DATA="false"; $env:MIDAS_DEV_SEED_DEMO_USER="false"; docker compose up --build

These variables persist for the current shell session. Open a fresh shell (or unset the variables) to return to default demo behaviour.

When MIDAS_DEV_SEED_DEMO_DATA=true, MIDAS also seeds deterministic synthetic drift data by default so the Drift Overview is populated for demos. Set MIDAS_DEV_SEED_SYNTHETIC_DRIFT=false to suppress synthetic drift while keeping the structural demo data. Dev/demo-only; idempotent.

Run with Postgres: uncomment the postgres service and environment block in docker-compose.yml.

Go (no dependencies)

go run ./cmd/midas

Then open http://localhost:8080/explorer and sign in with demo / demo.

⚠️ Auth mode defaults to open for local development. Before exposing MIDAS to a network, set MIDAS_AUTH_MODE=required and configure MIDAS_AUTH_TOKENS. See Authentication.

First API evaluation

MIDAS v1 evaluates against explicitly declared structure. The default docker compose up --build flow seeds a complete demo chain (BusinessService → Process → Surface → Profile → Grant → Agent), so a fresh checkout can call /v1/evaluate immediately against a seeded surface. Below, we use the seeded Credit Assessment surface:

curl -s -X POST http://localhost:8080/v1/evaluate \
  -H "Content-Type: application/json" \
  -d '{
    "surface_id":     "surf-v2-credit-assess",
    "process_id":     "proc-credit-assessment",
    "agent_id":       "agent-v2-evaluator",
    "confidence":     0.91,
    "consequence":    {"type": "risk_rating", "risk_rating": "low"},
    "context":        {"customer_id": "C-8821"},
    "request_id":     "req-demo-001",
    "request_source": "lending-service"
  }'

Expected response:

{"outcome":"accept","reason":"WITHIN_AUTHORITY","envelope_id":"...","explanation":"Request is within granted authority and may proceed.","policy_mode":"noop","audit_status":"recorded"}

Retrieve the full governance record:

curl http://localhost:8080/v1/decisions/request/req-demo-001?source=lending-service

For an end-to-end Postgres walkthrough including control-plane apply, surface approval, profile authoring, and grant binding, see docs/guides/quickstart-first-evaluation.md.

Kubernetes / Helm

MIDAS includes a Helm chart at charts/midas. For a reviewer-friendly Kubernetes walkthrough, including required Secrets, external Postgres configuration, install, port-forwarding, health/readiness/metrics checks, and uninstall, see docs/getting-started/kubernetes.md. The chart-local reference is charts/midas/README.md.

---

Authority Model

Authority flows in one direction:

DecisionSurface → AuthorityProfile → AuthorityGrant → Agent

Surface — what is governed (a business decision boundary). Carries name, domain, owner, required context keys. Does not carry thresholds.

Profile — how much authority is permitted on a surface. Carries confidence threshold, consequence limit, escalation mode, policy reference.

Grant — thin link from an agent to a profile. No governance semantics of its own.

Agent — any autonomous actor: AI model, automated service, or human operator.

See docs/core/authority-model.md.

---

Integrity Guarantee

Every evaluation is atomic, deterministic, and produces a tamper-evident audit chain. The envelope — outcome, authority evidence, audit events — is written in a single database transaction. Either everything commits or nothing does.

Audit events are hash-chained in sequence. Each event's SHA-256 hash is derived from the previous event's hash. The final event hash is anchored in the envelope's Integrity section. If any event is modified, deleted, or inserted after the fact, the chain breaks at that point.

Verification requires only the stored event hashes and the anchored final hash on the envelope — not access to application secrets. See docs/core/envelope-integrity.md.

---

Configuration

Database

Variable	Default	Description
MIDAS_STORE_BACKEND	memory	memory or postgres
MIDAS_DATABASE_URL	(none)	PostgreSQL connection string. Required when MIDAS_STORE_BACKEND=postgres.

The schema is applied automatically at startup (internal/store/postgres/schema.sql). No separate migration step is needed.

Authentication

Variable	Default	Description
MIDAS_AUTH_MODE	open	open (no auth, dev only) or required (bearer token enforced).
MIDAS_AUTH_TOKENS	(none)	Semicolon-separated entries: token|principal-id|role1,role2. Required when MIDAS_AUTH_MODE=required.

Generate tokens with openssl rand -base64 32, then:

export MIDAS_AUTH_TOKENS="<token>|svc:deploy|platform.operator;<token2>|user:alice|platform.admin,governance.approver"

Roles: platform.admin, platform.operator, platform.viewer, governance.approver, governance.reviewer.

MIDAS_AUTH_MODE	MIDAS_AUTH_TOKENS	Result
required	Set	Bearer token auth enforced
required	Unset	Fatal — no tokens configured
open	—	No auth — UNSAFE FOR PRODUCTION logged

Key environment variables

Variable	Default	Description
MIDAS_LOG_LEVEL	info	info or debug
MIDAS_EXPLORER_ENABLED	(auto)	true enables Explorer UI. Auto-enabled in memory mode.
MIDAS_DISPATCHER_ENABLED	false	true starts the Kafka outbox dispatcher
MIDAS_DISPATCHER_BATCH_SIZE	100	Outbox rows claimed per poll cycle and upper bound for topic-group publish/mark batches
MIDAS_DISPATCHER_POLL_INTERVAL	2s	Active runtime sleep between empty-queue poll cycles
MIDAS_DISPATCHER_MAX_BACKOFF	30s	Active runtime maximum backoff after consecutive poll errors
MIDAS_KAFKA_BROKERS	(none)	Comma-separated host:port. Required when dispatcher enabled.

Full variable reference: docs/operations/deployment.md.

---

Documentation

Document	Contents
docs/getting-started.md	Prerequisites, install paths, memory-mode first evaluation
docs/getting-started/kubernetes.md	Kubernetes and Helm quickstart: kind/minikube-style local validation, required Secrets, Helm install, smoke tests, optional Explorer mode, and uninstall
charts/midas/README.md	Helm chart reference: values, required Secrets, deployment options, probes, metrics, dispatcher settings, and limitations
docs/guides/quickstart-first-evaluation.md	End-to-end Postgres walkthrough: midas init quickstart → Surface approval → Agent/Profile/Grant → Profile approval → /v1/evaluate
docs/examples/control-plane.md	Self-contained control-plane example bundles: plan/apply, Surface/Profile approval, evaluate, idempotency/conflict checks, and evidence integrity
examples/control-plane/	Five reviewer-friendly YAML bundles covering accepted, escalated, and request-clarification outcomes without relying on demo seed data
docs/explorer.md	Explorer sandbox: usage, endpoints, auth, envelope inspector
docs/control-plane.md	Apply, plan, surface lifecycle, versioning
docs/core/platform-contract.md	Core MIDAS API, YAML resource, runtime evaluation, evidence, and eventing contract
docs/core/authority-model.md	Surfaces, profiles, grants, the authority chain
docs/core/runtime-evaluation.md	Evaluate endpoint, outcomes, idempotency, audit
docs/core/envelope-integrity.md	Envelope structure, hash chain, integrity verification
docs/core/data-model.md	PostgreSQL schema reference
docs/guides/lifecycle-management.md	Inferred structure lifecycle: promote and cleanup
docs/guides/authentication.md	Local IAM, OIDC/SSO, and API bearer token authentication
docs/guides/rego-policies.md	Policy behavior: NoOp default and future direction
docs/operations/runtime-readiness.md	Operator runbook: pilot deployment, observability, incident response, benchmark interpretation, fail-mode guidance
docs/operations/deployment.md	Surface lifecycle, Postgres pool, runtime metrics, runtime safety
docs/operations/performance.md	Reference inline-evaluation benchmarks (direct + HTTP) and interpretation
docs/operations/escalations.md	Escalation outcomes, listing and resolving
docs/operations/events.md	Outbox, dispatcher, Kafka, event contracts
docs/operations/integrations.md	Kafka integration, SSO/OIDC
docs/api/http-api.md	Complete HTTP API reference
docs/architecture/architecture.md	Deep architecture overview

---

License

Apache License 2.0