For companies

The compliance reality

Three forces are converging on every company that ships AI agents:

1. Fiduciary duty. Boards now treat AI as material risk. "We use a third-party model" is not a defence when the agent makes a decision that affects a customer.
2. Multi-jurisdictional exposure. EU AI Act, UAE §11, US sectoral rules, the Singapore MAS framework — most companies operate under at least two and increasingly under five or more. The cost of bespoke compliance scales with jurisdictions × capabilities × release velocity.
3. Regulator expectation has caught up to AI velocity. Supervisors increasingly expect real-time visibility, not quarterly attestations. The reporting cycle is closing on minutes, not months.

Iqrar is built for that reality. Every benefit on this page maps back to one of those three forces.

1. One pane of glass over every agent you ship

Most enterprises run agents across half-a-dozen incompatible runtimes — a CrewAI crew in one team, a LangGraph deployment in another, a Bedrock Agent for the data-science group, an OpenAI Assistants integration in customer support, a custom Vercel-AI bot on the marketing site. Each one logs into a different system, has a different schema, and answers compliance questions in a different format.

Iqrar collapses that into one continuously-updated picture spanning every framework, runtime, and cloud:

Why this matters operationally: the dimensions above are derived at the SDK boundary, not at any runtime. Switching from CrewAI to LangGraph (or shipping your first AutoGen agent next to your existing Mastra fleet) doesn't break the dashboard. Your agent-platform decisions are decoupled from your governance posture — which is the property an enterprise actually needs to keep both moving.

For your CISO and compliance leadership: the answer to "do we know what our agents are doing?" changes from "we have to ask each team" to "let me show you the dashboard."

2. Change agent behaviour from the platform, on the fly

Beyond compliance, Iqrar gives you a runtime control plane over your own fleet. From the dashboard your platform/SRE/compliance team can:

• Elevate logging on a single agent, a capability set, or the whole fleet — for incident investigations, vendor evaluations, A/B comparisons, or simply because you've shipped a new prompt and want a 24-hour debug window.
• Drop sample rate for a noisy capability without a code change, then return to baseline.
• Pause a capability across every agent that exposes it within 60 seconds — the kill-switch you'd otherwise build with a feature-flag service plus a deploy.
• Resume a paused capability with the same one-click flow, and have the entire lifecycle recorded in the audit chain.

Each of these is a signed internal directive, structurally identical to a regulator-issued directive, except issued under your own org-level signing key. Agents apply it on the next 30-second sync without a deploy. The directive itself is recorded in the audit chain — so "who turned debug logging on for the credit-decision agent at 2:14 a.m." is itself answerable.

This is the operational lever your platform team has been building piecemeal — feature flags here, log levels there, kill switches in a third place. Iqrar consolidates it into one signed, auditable surface that works regardless of which framework the agent runs on.

3. Real-time supervisory inquiries with a built-in notification loop

When a regulator opens an inquiry, the typical response cycle today is days to weeks — discovery letter → legal review → engineering pulls logs → counsel reviews → response. Iqrar collapses that into minutes, with a notification path the company and engineering team are inside, not outside:

1. Regulator issues a signed directive elevating verbosity (or scoping a capability) for the inquiry — targeted by jurisdiction, agent ID, or capability set, with a defined time window.
2. Affected agents apply the directive within 60 seconds. The change is recorded in their audit chain as directive.received → directive.applied, signed by both the regulator's authority key and the agent's identity key.
3. The company is notified in real time — Slack, email, webhook, or PagerDuty integration on the org-level dashboard. The notification carries: which authority issued it, which agents are affected, what the change is, the time window, and the issuer's stated justification (the directive carries a justification field).
4. Developers responsible for those agents are notified through the same channel routing — by team, by capability owner, or by codeowner inferred from the agent's agent_id. Engineering is in the loop from minute zero, not from the legal team's forwarded PDF on day three.
5. The elevated logging window is bounded. When the directive expires, agents return to baseline automatically. The full lifecycle — receipt, application, behavioural change, expiry — is in the audit chain.
6. Your compliance team can mirror the regulator's view. The dashboard surfaces the same query the regulator can run, so legal isn't reverse-engineering what the supervisor saw — they see it alongside.

The notification loop is the load-bearing piece. Companies don't need to be surprised by an audit; they need to be informed and prepared. Iqrar's posture is that being supervised is a normal operating state, not a crisis — and the platform makes it feel that way to your engineering org.

4. One integration covers every jurisdiction

Your engineering teams add @iqrar/agent (or iqrar-agent in Python) to each agent codebase once. From that point:

• New jurisdictions are added by config, not code: jurisdictions: ["EU", "AE-DIFC", "SG"].
• The SDK fetches, verifies, and merges every supervisory ruleset using a strictest-wins N-way merge — your code stays single-jurisdiction.
• A new regulator publishing a ruleset doesn't trigger a release cycle. Your agents pick it up on the next sync.

For a company with 30 agents across 5 jurisdictions, this is the difference between one engineering integration and 30 × 5 = 150 compliance touch-points rebuilt every time a rule changes.

5. Compliance becomes automatic, not aspirational

Tier classification, obligation filtering, payload retention, disclosure strings — all derive from the active ruleset, not from your code. When a regulator publishes a new tier classifier or new obligation, your agents inherit the change. When your agent's capability set changes (you add a credit-decision feature), its tier and obligations recompute automatically.

What this removes from your roadmap:

• Bespoke compliance code in every agent
• Manual review of every regulatory update for code impact
• Per-jurisdiction conditional branches
• Custom retention/log-rotation policies per jurisdiction

What it adds: a single configuration surface — declared capabilities per agent. That's it.

6. Board-grade audit trail by default

Every event your agents emit is committed to a per-agent tamper-evident hash chain, then to a Merkle tree whose root is published to Sigstore Rekor — a public transparency log neither Iqrar nor your company controls.

For your board this means:

• "Did the agent log it?" is answered with a cryptographic inclusion proof, not a screenshot.
• "Was the log tampered with?" is structurally impossible to do undetectably — any change invalidates the inclusion proof against Rekor.
• "What did the agent know at the time?" is answered by the rule_hash stamped on every event, traceable back to the signed regulator bundle.

The technology underneath is the same chain-of-custody used by the open-source supply-chain world. Your auditor doesn't need to trust Iqrar's infrastructure. They verify against a public log.

7. Compliance-grade visibility, alongside your existing observability

Your engineering observability stays where it is — LangSmith, Galileo, Datadog, or whatever your engineering team chose. The SDK adds structured tags to spans your tracing stack already captures (rule hash, risk tier, jurisdiction), so engineers can pivot from a failing span to the obligation that governed the run.

Separately, the regulatory channel produces a compliance-grade view of the fleet — uniform across every framework you ship:

• Per-agent dashboards at /admin showing live invocations, tier, obligations, recent decisions
• Per-jurisdiction views aggregating agents by supervisory authority
• Per-team and per-capability views for internal accountability
• Drill-down to specific decisions and human-review status
• Filter by capability, tier, model, tool, framework, or jurisdiction

The two channels never share a payload. The engineering channel carries full content for your engineers; the regulatory channel is per-recipient encrypted and carries only what each recipient is entitled to receive. That separation is what makes the composition legal at the regulatory boundary for many workloads.

8. Structural separation: rules vs. infrastructure

A novel governance pattern underpins the whole platform: the foundation governs the rules. Iqrar (the operating entity) runs the infrastructure under contract. The SDK pins the foundation registry on first boot; unsigned rules are refused. Verification is sticky.

Why this matters for your legal and procurement teams:

• The vendor cannot unilaterally change what your agents are required to do.
• A regulator's authority is verifiable from the registry, not from a vendor relationship.
• Vendor lock-in is bounded — the wire format is documented, the SDK is MIT-licensed, the rule format is a public schema.

This is the answer to the "what if Iqrar gets acquired / disappears / pivots?" diligence question that comes up in every enterprise procurement. The structure is designed for that question.

9. Implementation overview

A typical engagement runs in four phases:

Most engineering teams complete the SDK integration per agent in a single sprint. The longer phases are governance — confirming the capability mapping with legal, agreeing the obligation set with compliance, and dry-running the regulator-facing flows.

10. How Iqrar relates to other tools you may have

Three distinct categories of tooling have grown up around production AI agents.

• Engineering observability (LangSmith, Galileo, Arize, Datadog LLM) captures content for your developers to debug and improve the agent. Buyer: engineering. Success metric: the agent works better.
• Governance dashboards (Credo AI, Holistic AI, Robust Intelligence) help your compliance team produce documentation and track risk assessments. Buyer: compliance. Success metric: producing a binder when the regulator asks.
• Regulatory infrastructure (Iqrar) sits between your agent and the regulator — authority-anchored rule bundles enforced inside the SDK at runtime, with per-recipient cryptographic separation so the regulatory channel never carries content the regulator isn't entitled to. Buyer: the regulator-facing function (compliance + legal + GR). Success metric: the regulator trusts the runtime, not just the paperwork.

Run all three, or any subset that fits your stack. They sit at different boundaries and the composition is explicit. The same byte of prompt text that is required in observability is prohibited on the regulatory channel for many workloads — Iqrar's per-recipient architecture is what makes that composition legal.

A typical regulated deployment runs Iqrar alongside one tool from each of the other two categories. Your engineering team keeps the observability stack they already chose; your compliance team keeps the governance dashboard their workflow runs on; Iqrar adds the runtime evidence layer that backs both.

11. Pricing posture

Pricing is established per engagement based on agent volume, jurisdictional coverage, and whether the deployment runs on shared Iqrar infrastructure or dedicated tenants. We don't publish a SaaS price list because the unit of value is jurisdictional coverage × agent fleet size, not seats. A typical first engagement is a 30-day commercial pilot with capped scope.

What this changes for your CTO

• One pane of glass across every agent platform you use — CrewAI, LangGraph, OpenAI Agents SDK, AutoGen, Bedrock, Vertex, hosted Assistants — without giving up the framework choice.
• One vendor surface for AI compliance instead of N (per jurisdiction) × M (per audit need).
• A runtime control plane for your own fleet — change logging, sampling, or capability state from the dashboard, signed and audited.
• The supervisory inquiry stops being a fire drill — regulators turn dials, the company is notified in real time, developers are looped in from minute zero.
• Compliance moves left, into the SDK, instead of right into post-hoc reporting.
• Audit becomes a property of your code, not a process imposed on top of it.
• The board question "are we compliant across our jurisdictions?" has a cryptographic answer, not a deck.

What's next

• Read the — the five primitives that make all of the above structural rather than aspirational
• Read what your regulators see in
• Explore the integrations your engineering teams already use in
• For pricing and engagement, contact us via the