Beta Limitations

Mandaitor is in invite-only beta. Access is reviewed before it is granted — request it here, and you will hear back within five business days. There is no self-service signup, and there is no waiting list you can be lost on: every request gets an answer.

This page tells you exactly what is production-ready, what is not, and where the rough edges are. It is the single source of truth for those boundaries — if you rely on a feature that is not listed here as stable, treat it as best-effort.

Stability Tiers

Tier	What it means
Stable	Production-ready. Breaking changes only with a 90-day deprecation window.
Beta	Feature-complete but may change based on feedback. 30-day deprecation window.
Preview	Experimental. Can change or be removed at any time.

API Surface

Stable

• POST /verify — mandate verification with reason codes and constraints.
• POST /mandates, GET /mandates/{id}, GET /mandates — mandate CRUD.
• POST /mandates/{id}/suspend, /reactivate, /revoke — lifecycle.
• GET /mandates/{id}/events, GET /events/{id} — audit log reads.
• POST /onboarding/request — public onboarding intake.
• API key authentication via x-api-key header.
• Signed Webhook Delivery — Webhooks are delivered via SQS with HMAC-SHA256 signatures (X-Mandaitor-Signature) and SSRF protection.
• Consent UX — Human-in-the-loop approval workflows for mandates (/consents).

Beta

• GET /mandates/{id}/evidence-pack — court-ready evidence export. Schema may gain fields but will not break existing ones.
• POST /verify?pom=sd-jwt-vc — Proof-of-Mandate Verifiable Credential issuance.
• Agent Identity Registry — Persistent agent identity with DID and key rotation (/agents).
• Marketplace — Community-contributed taxonomy definitions and mandate templates (/marketplace).
• MCP Authorization Server — Agent sessions for the MCP server and the execution API, bound to a key when the client can sign proofs (/mcp/token, /mcp/sessions/{id}). /mcp/authorize and /mcp/policy, which decided a tool call and left the acting to the agent, were removed in October 2026; see MCP Authorization Server.
• Runtime Assurance Loop — Validated Core → Ops → Trust Data → Dashboard evidence publication. The runtime-authorization snapshot it publishes is a fixture of the retired /mcp/authorize path's trace until it reads execution receipts; see Runtime Assurance Loop.
• Tenant Access Management — Tenant-scoped role assignments for canonical subject IDs, including TENANT_ROLE_ASSIGNED and TENANT_ROLE_REVOKED audit events.
• Tenant Audit/SIEM Export — Tenant-scoped audit exports for SIEM ingestion, guarded by events:export RBAC and cursor-based pagination.
• Admin dashboard at dashboard.mandaitor.io. UI may evolve rapidly.

Preview

• Executions — Mandaitor performs one business operation for an agent, against hosted sandboxes, and signs a receipt of the outcome (/executions, /tools, /tenants/{id}/tools, /tenants/{id}/executions). See Executions and what the preview does not do yet.
• MCP Server — Mandaitor as a remote MCP server: an agent's MCP client lists the tools its mandates could back and calls them, each call an execution (/mcp). See MCP Server.
• Request-bound decisions — /verify's successor for an integrator whose own system performs an agent's operation: an authorization for one request, redeemed once (/decisions). See Request-bound Decisions and what the preview does not do yet.
• Connectors and demo sandboxes — Connections to enterprise systems, and Mandaitor-hosted sandboxes that emulate them (/connectors/catalog, /tenants/{id}/connectors).
• Verifiable Intent (VI) Credential — Compatibility layer for Mastercard/Google VI spec (/mandates/{id}/vi-credential).
• Drift Monitor — Ontology-based semantic analysis for drift detection (/drift). Drift remains advisory and does not change authorization decisions.
• EUDI Wallet session APIs (/eudi/*).
• SCIM provisioning endpoints (/scim/v2/*).
• DID document resolution (/.well-known/did.json).
• Trust signal endpoint (/trust-signals).

Constraint enforcement

A mandate's constraints object accepts any key. Not every key is evaluated, and until 2026-09-10 there was no way to tell from the API which were. There is now: the creation response names unsupported keys, and every verification response reports what it checked.

What POST /verify evaluates

Constraint	Status
time (not_before / expires_at)	Enforced — the mandate's validity window. The top-level expires_at that POST /mandates accepts counts too; when both are set, the earlier wins
require_mfa	Enforced — denies with MFA_REQUIRED unless the request context carries mfa_timestamp, amr including mfa, or loa of SUBSTANTIAL/HIGH
escalation_rules.deviation_above_percent	Enforced when the request supplies context.deviation_percent
scope.effect: DENY	Enforced — a matching DENY mandate beats any ALLOW
transaction_limits	Not enforced here. Executions enforce max_amount and max_total (Executions)
escalation_rules.amount_above	Not enforced here. Executions only: above it, a person approves
max_uses	Not enforced. Stored, restricts nothing
geo_fence	Not enforced. Stored, restricts nothing
ip_whitelist	Not enforced. Stored, restricts nothing
rate_limits	Not enforced here. Executions count max_count (Executions). For request-rate limits see Rate Limiting — those are enforced per tenant at the gateway
time_window	Not enforced under this name. The stored key is time; a time_window inside constraints is ignored
Anything else	Not enforced. constraints is an open object, so a typo is accepted silently by the schema — but it will be named in unsupported_constraints

How the API tells you

POST /mandates still creates the mandate, and adds:

{
  "mandate_id": "mnd_...",
  "unsupported_constraints": ["geo_fence", "max_uses"],
  "unsupported_constraints_message": "These constraints are stored on the mandate but are not evaluated by POST /verify: geo_fence, max_uses. ..."
}

POST /verify reports, on every decision where a mandate matched:

{
  "decision": "ALLOW",
  "evaluated_constraints": ["require_mfa", "time"],
  "unevaluated_constraints": ["geo_fence", "transaction_limits"]
}

If you want a hard failure rather than a disclosure, treat a non-empty unsupported_constraints at creation as an error. The getting-started guide shows that check.

Proof-of-Mandate

A PoM's constraints_snapshot now contains only the constraints the issuing path evaluated, so a relying party can treat every key in it as enforced. Constraints the mandate carries that the path did not evaluate are named — by key, without their values — in unenforced_constraints. Previously transaction_limits was included unconditionally, so a credential from /verify asserted an amount limit that nothing had checked.

Deprecation

max_uses, geo_fence, ip_whitelist, rate_limits keys other than max_count, time_window and the /verify use of transaction_limits are deprecated as of 2026-09-10. POST /mandates is a Stable endpoint, so they will keep being accepted for the 90-day deprecation window and will be rejected with a 400 from 2026-12-09. Mandates created before then keep working; the keys simply never did anything.

Executions (Preview)

Executions let an agent ask Mandaitor to perform one business operation. In the beta:

• No tool can be enabled yet. Both registered tools, sap.purchase_requisition.release and servicenow.requested_item.approve, wait for the procurement taxonomy that defines their business action. Until that is loaded, GET /tools lists them as unavailable, and every request for either is refused with 403 TOOL_NOT_ENABLED.
• Hosted sandboxes only. An execution runs only on a connector to a Mandaitor-hosted sandbox. Any other connector is denied with CONNECTOR_NOT_PERMITTED.
• ServiceNow sandboxes. No sandbox's credential is shown: Mandaitor holds it, and only its executor writes to the sandbox. A ServiceNow sandbox provisioned before October 2026 showed its credential once, and whoever kept it can approve items without Mandaitor until the credential is replaced. ServiceNow keeps no version a write can be made conditional on, so a person's decision that lands between Mandaitor's last read of an item and its write is overwritten.
• Environments are fixed and share one policy version. An agent or a connector stays in the environment it was created in; to move one, create another. A change to the tools enabled in any environment means an approval still waiting, in any environment, must be given again.
• Replacing a credential changes only its secret. The URL and user name stay, and another account is another connector. Mandaitor's own signing keys are not rotated yet.
• An outcome no read-back settles needs a person. Mandaitor reads an UNKNOWN execution back for about 41 hours and never writes it again. What that does not settle, a person with tenant:write resolves, on the execution's page in the dashboard or with POST /tenants/{id}/executions/{executionId}/resolution. Mandaitor's operators are alerted when an execution is left for a person, but nothing tells your tenant: the dashboard's Executions page marks the ones waiting for a person, and GET /tenants/{id}/executions?state=UNKNOWN lists them.
• The agent reads for the outcome. An allowed request is answered before Mandaitor writes it. The agent reads the execution until it is final; nothing notifies it.
• Only a session bound to a key. The execution API accepts only a session issued with a DPoP proof, and every request carries a fresh proof (Sessions bound to a key). A client that cannot sign proofs reaches executions through the MCP server, which accepts bearer sessions. A session lasts an hour, and there are no refresh tokens: the client asks /mcp/token again.
• One approver per mandate. The approver is escalation_rules.escalate_to, or else the principal, named by subject ID. There are no approver groups or roles yet. Nothing stops the principal from also being the person who set up the agent.
• One email, no reminders. The approver is emailed once that an approval is waiting, with a link to it. The email goes to the verified sign-in email of their Mandaitor account in the tenant, or else the email on their role assignment there. With neither, nobody is told, and the request's notification says so (Approver Notifications). There is no other channel. The approval appears in the approver's Consent inbox and on the execution's page, and expires after at most 24 hours.
• No cancellation. An agent cannot withdraw a request. An approval nobody wants is rejected, or left to expire.
• Cumulative limits are hard caps in UTC calendar windows. transaction_limits.max_total and rate_limits.max_count count per mandate, in a clock hour, a UTC day, an ISO week or a calendar month, never in a rolling window. Past one, an execution is denied, and no approval can carry it over. There are no limits per agent or per action. The taxonomy templates' max_daily_total and max_*_per_day keys, and the dashboard's own rate-limit shape, are not read: a mandate that uses them backs no execution.
• Not metered. Execution requests do not count against the monthly allowance today, whether they come through /executions or the MCP server.
• The MCP server is for registered agents only. A person cannot sign in through an MCP client yet. Its calls answer within about 20 seconds; there is no stream and no progress while a call waits, and it serves tools only, no resources or prompts. Standard MCP clients hold bearer sessions, which last 15 minutes: keep them as secret as the agent's key.
• The MCP server takes 60 requests a minute from each agent, and 25 a second from every agent together. Past either, a request is answered 429 (Rate Limiting). Keep one connection open rather than connecting for each call, and wait a few seconds between get_execution checks on an execution that waits for an approval.

Request-bound decisions (Preview)

Request-bound decisions let your own system's enforcement point ask before it acts for an agent. In the beta:

• No approvals. A request that needs a person's approval is answered REQUIRE_APPROVAL with no authorization, and no approval is raised.
• Procurement actions are unknown. The procurement taxonomy is not loaded yet, so a procurement.* action is denied with UNKNOWN_ACTION. Actions of the loaded taxonomies are decided.
• A redemption does not decide again. It refuses an agent suspended or revoked since the decision, a mandate changed since, and a tenant kill switch requested since, but a DENY mandate created after the decision does not stop it within the authorization's five minutes.
• A lost answer costs a decision. A redemption cannot be repeated: if its answer is lost, the retry is answered ALREADY_REDEEMED. Do not act on it; ask for a new decision.
• Limits are charged when the authorization is given. It counts against the mandate's cumulative limits whether or not it is redeemed, and an authorization that expires unredeemed does not give its share back.
• Mandaitor sees the redemption, not the operation. What your system does after a redemption is outside what Mandaitor records.
• Metered. Each decision counts 2 units, an ALLOW or not; redemptions do not count.

Operational Limits

• Region: All data resides in eusc-de-east-1 (AWS European Sovereign Cloud). Cross-region replication is not yet available.
• Throughput: See Rate Limiting. Limits are enforced per source address (6,000 requests per 5 minutes) and per route, on top of a platform-wide 500 req/s. Free-tier accounts are additionally capped at 100,000 billable units per calendar month, after which API keys are refused until the month rolls over (dashboard sign-in is not affected); paid plans have no monthly cap. See Monthly Allowance.
• Retention: The Horizon 0 GA readiness policy now defines machine-readable defaults: audit events, evidence packs, and tenant operational records are retained for 2,555 days, while deletion and export requests target 30 days.
• SLA: Beta operation is best-effort against a 99.5% service objective. No SLA is measured or contracted yet; the machine-readable GA readiness policy records the SLA posture as planned and the data-residency attestation as beta_supported (the platform runs in the AWS European Sovereign Cloud, eusc-de-east-1; a formal residency attestation is GA work).

What Is Not Yet Supported

• Multi-region failover.
• Customer-supplied encryption key import beyond Mandaitor-managed customer-managed KMS keys.
• On-prem / self-hosted deployment.
• GDPR Article 20 automated data export (manual export on request).

Known Rough Edges

• Evidence pack export returns JSON only. A PDF renderer is available in the dashboard via browser print.
• Metering corrected 2026-09-10. Denials, verifications issuing a Proof-of-Mandate, and every POST /mcp/authorize (removed since) were previously not counted at all. They are now. Metered volume on those paths rises without your traffic changing. See Monthly Allowance.
• Unenforced constraint keys are accepted rather than rejected, because POST /mandates is a Stable endpoint under a 90-day deprecation window. See Constraint enforcement.
• Verify Playground API key is stored in sessionStorage and does not persist across browser tabs.
• Compliance dashboard verification badges may briefly show asserted immediately after a claim is added, before the next weekly generator run reclassifies it.
• Runtime Assurance publication depends on the generated trust-data.json artifact. If live trust data is unavailable, the dashboard uses documented fallback data so reviewers can still inspect the expected cockpit layout.

Reporting Issues

• Security: security@mandaitor.io. Response times and scope are in SECURITY.md — acknowledgement within five business days, from a single maintainer in European business hours. Ask in your first mail if you need an encrypted channel.
• Bugs: GitHub issues.
• Questions: support@mandaitor.io, answered within five business days.

Going to General Availability

We will announce GA with:

1. A 30-day notice on this page and the dashboard.
2. An explicit changelog of every breaking change between beta and GA.
3. A published, measured SLA that applies to eligible GA plans.
4. A data residency attestation backed by the machine-readable GA readiness policy and generated trust data.

Until then, please treat Mandaitor as beta software: production-safe for pilot workloads, but not yet backed by a formal support agreement. Customer-managed KMS at rest, tenant audit/SIEM export, retention defaults, and data-residency posture are now documented as Horizon 0 GA-readiness commitments rather than deferred GA work.