For regulators

The supervisory reality

Three structural problems define AI supervision today:

1. Rule distribution lags AI velocity. A guidance note published as a PDF is parsed by counsel, translated into compliance code by engineers, and reaches deployed agents months later. By then the technology has moved.
2. Audit depends on the supervised entity's cooperation. When you ask "what did your agent do?" you receive what they choose to give you, in a format they choose to give it in, anchored in databases they control.
3. Infrastructure and rule-authoring authority are conflated. The vendors that distribute compliance rules are the same ones holding the audit logs. There is no structural separation between author and operator.

Iqrar is designed against those three problems. Each benefit on this page maps back to one of them.

1. Live visibility over every agent in your jurisdiction

Iqrar gives you a continuously-updated picture of the agent population under your supervision. The eight rows below are the load-bearing dimensions — each maps directly to a supervisory question you are already trying to answer, and every value is derived at the SDK boundary, signed by the agent's identity key (patent §5.6), and committed to the public Sigstore Rekor log.

Aggregate views collapse the same data by operator, capability, tier, model, region, framework, or data class. You can ask "every Tier-3 agent running credit_decision against EU consumers, on gpt-4o-eu, with no human-review step in the last 7 days" and get the answer in a single query — without operator cooperation.

The data surface is not vendor-defined. It is a property of the SDK boundary. What you see in the dashboard is exactly what the agent committed; what the agent committed is exactly what is in Sigstore Rekor; and what is in Rekor is independently verifiable against your authority's signed ruleset.

2. Distribute rules at machine speed

Your jurisdiction publishes a signed rule bundle once. Every agent in your scope picks it up within 60 seconds, verifies the signature against the foundation registry, and applies the new tier classifiers, obligations, and disclosures automatically.

Concretely:

• A new tier classifier (e.g. adding emotion_recognition_workplace to the prohibited list) propagates without any company writing code.
• A new obligation (e.g. requiring a new disclosure phrasing) lands at the disclosure call site automatically.
• A new effective date is honoured by every agent in scope.

What changes for your team: rule publication moves from "PDF + compliance assessment cycle" to "signed bundle published to the registry." Within a minute, the entire agent fleet under your supervision is governed by the new bundle.

3. Issue runtime directives without a release cycle

Beyond rule bundles, you can issue signed runtime directives that take effect at agent runtime without redeployment:

• verbosity — elevate audit detail (e.g. for a supervisory inquiry).
• sample_rate — change what fraction of events are persisted in full.
• operational_pause — suspend a named capability for a defined window.

Each directive carries a scoped target (jurisdiction / agent ID / capability), a time window, and your signature. Agents independently verify the directive against the pinned registry, refuse anything whose scope does not encompass their jurisdiction, and emit directive.received / .applied / .skipped / .rejected events into their audit chain — so the directive's enforcement decision is itself committed.

For a supervisory inquiry, this means: you don't wait on the firm. You turn the dial and the answer comes back from the SDK directly.

4. Verify agent behaviour without trusting the operator

Every telemetry event the worker accepts is appended to a per-agent tamper-evident hash chain. A cron job every minute builds an RFC 6962 Merkle tree over the new entries, signs the root with a foundation key, and submits the signed tree head to Sigstore Rekor — a public transparency log neither the operator nor Iqrar controls.

You can issue a signed audit challenge containing:

• A predicate over the agent population (jurisdiction, capability set, time window, action type)
• A deterministic sampling rule
• (Optional) a binding to a specific directive

The worker verifies your challenge signature against the pinned registry, scope-checks the predicate against your recorded jurisdiction, resolves matching agents, applies the sampling rule (you can independently recompute it), builds Merkle inclusion proofs against the smallest STH that covers each entry, and returns { proofs[], rekor_url }. Every proof is verifiable locally against Rekor. You do not need to trust Iqrar's infrastructure.

When the challenge is bound to a directive, the response also includes the directive's own audit-chain lifecycle entries with inclusion proofs — so you can verify directive application alongside the action records the directive shaped.

This is the . Patent §8.3 in full.

5. Source-boundary channel encryption

Telemetry events are not merely encrypted in transit. They are encrypted at the SDK boundary, per recipient, before they enter Iqrar's routing infrastructure.

For each event the SDK:

1. Generates an ephemeral ECDH-P-256 keypair (forward secrecy per event).
2. Derives a per-recipient symmetric key via HKDF-SHA256.
3. Encrypts once per recipient with AES-256-GCM.
4. Posts the resulting envelope to /telemetry/channeled.

The worker stores ciphertext segments by recipient_kid and is structurally unable to decrypt — it has no recipient private keys. You retrieve your segments at /recipients/<your-kid>/events. The operator cannot read what is addressed to you, and the worker cannot read it either.

Crucially, the SDK emits a channel.classified audit event for every channeled emission, recording which recipients each segment was addressed to. A downstream filtering attack — where the worker silently drops some recipients' segments — is detectable, because you can compare what you received against what the SDK committed.

6. Structural separation: foundation governs, operator runs

A novel governance pattern underpins the platform: the Iqrar Foundation governs the rules (registry of authorities, signed bundles, directives). The operating entity runs the infrastructure under contract. The SDK pins the foundation registry on first boot; unsigned rules are refused.

For you this means:

• The operator cannot change what agents are required to do.
• Your authority is recorded in the foundation registry, signed by a threshold of foundation root keys, and verifiable end-to-end.
• The infrastructure-operator role is replaceable without re-establishing the rules — change of operator does not change the trust model.

The foundation white paper at iqrar.foundation describes the multi-party governance pattern in full. We expect the foundation board to include regulator representatives over time.

7. The partnership model

We design Iqrar in collaboration with the regulators we serve. A typical engagement looks like:

The MOU framework is intentionally light. The foundation registry is the technical instantiation of your authority; the MOU records the policy commitment.

8. Jurisdictional engagement (calibrated)

We're calibrating public disclosure of in-flight regulator engagements. Where a partnership has been formally announced, the foundation registry lists the authority's kid, scope, and capabilities publicly. Where discussions are pre-MOU, we don't publish.

If you'd like to evaluate Iqrar for your jurisdiction, see Schedule a briefing below.

9. Technical architecture brief

Rules flow through five primitives:

1. Foundation registry — the signed root of trust listing authorities and their public keys.
2. Signed rule bundles — your ruleset + optional directives, signed by your authority key.
3. Per-event hash chain → Merkle tree → Sigstore Rekor — the immutable commitment of every agent's behaviour.
4. Source-boundary channel encryption — per-recipient encryption at the SDK before routing.
5. Predicate-scoped audit challenges — your interface for surgical supervisory inquiry.

The full technical treatment is at and . carries the diagrammatic version.

10. What you don't see without asking

Credibility requires naming the limits. The standing visibility above is what the SDK commits by default. Three categories are deliberately out of scope until you ask for them — typically via a signed directive or audit challenge:

• Plaintext prompts and full system templates. Below Tier 3 these are auto-summarised before transmission; at Tier 3+ they are retained but encrypted to the channels authorised on the agent. If your authority isn't on the channel, you don't see plaintext. To pull a prompt, issue a directive elevating verbosity (which the agent records) or a challenge naming the predicate.
• Per-user PII. Channel-encrypted to the recipient class authorised for it. Operators can authorise a regulator channel during a supervisory inquiry — the directive that grants it is itself signed and committed, so the access is auditable.
• Inference vendor model attestation. The agent declares its model name; we can't independently verify the operator routes inference where they say they do. Closing this requires either (a) a challenge-response watermark from the inference vendor or (b) a signed attestation the operator publishes alongside the agent. Both are roadmap, neither is structural to today's deployment.

What this means in practice: for routine supervision, the dimensions in §1 are sufficient. For specific inquiries, every additional surface is gated by a signed instrument that is itself part of the audit record. Nothing about Iqrar's posture is "we just see everything." It is "you can prove what you saw, prove what you asked for, and the agent can prove what it gave you."

11. Foundation governance summary

• Foundation root keys: initial threshold 1-of-1; pre-Provisional B target 3-of-5.
• Authority registration: each authority pins a public key, declares scope (jurisdictions), and capabilities (e.g. rule_bundle, directive).
• Foundation board: governs root key rotation, authority admission, registry publication. We expect regulator representation over time.
• White paper: iqrar.foundation.

What this changes for supervisors

• Live inventory of every agent under your supervision — operator, origin, framework, capabilities, model, tools, data classes, human-review posture, in one continuously-updated view.
• Rule distribution moves from publishing to deployment — measured in seconds, not months.
• Audit becomes locally verifiable — anchored in a public transparency log, not in the supervised entity's database.
• Surgical inquiry replaces full-fleet data requests — you specify a predicate, you receive proofs.
• The limits of visibility are themselves auditable — you can prove what you saw, prove what you asked for, and the agent can prove what it gave you.
• Vendor-side governance is structurally bounded — the rules are yours; the infrastructure is operated under contract.

Schedule a briefing

Direct path. We don't ask you to fill in a marketing-automation form. Email the foundation contact listed at iqrar.foundation and we'll arrange a 45-minute briefing tailored to your jurisdiction's specific posture.

What's next

• Read the for the five cryptographic primitives in detail
• Read the for the inquiry interface
• Read the for the governance posture
• See what the supervised entities see in