Product

How IntentGate authorizes every agent call

Each tool call hitting the gateway runs through four checks. The first failure short-circuits the rest; success forwards the call to the upstream tool server. Every decision lands in the tamper-evident audit chain.

1 · Capability

Did we issue this token?

Caller presents a signed capability token. HMAC verification. Revocation lookup. Scope coverage check. Fail-closed if the revocation store errors.

Learn more →

2 · Intent

What is the agent trying to do?

The extractor classifies the prompt into a structured recommendation: allowed tools, forbidden tools, confidence, rationale. Optional but powers expressive policy.

Learn more →

3 · Policy

Does policy permit it?

Your Rego policy decides allow / block / escalate-to-human with a human-readable reason and an optional requires_step_up advisory.

Learn more →

4 · Budget

Inside the agent's budget?

Per-agent and per-tenant rate and cost ceilings. Refusing the 101st call this hour from an agent budgeted for 100.

Learn more →

Opt-in for high-stakes agents

Memory provenance — intent verification, harder to fool

The intent check above pins each tool call to the user's authenticated prompt. For agents that read from a memory store — RAG corpus, vector database, conversation scratchpad — IntentGate offers an additional check that verifies the memory inputs which shaped the call. Off by default; switched on per-tenant for finance, healthcare, legal, and any deployment where the cost of an agent acting on tampered memory is catastrophic. Closes the sophisticated case of OWASP AAI03 (Memory Poisoning) end-to-end.

Try the attack

An attacker has planted a fake vendor IBAN in your agent's memory store. Click Run, then flip the toggle and click Run again.

Memory provenance:
Agent's memory store
mem-001 Acme Corp IBAN: NL12ACME0123456 signed
mem-002 Acme Corp IBAN: NL00ATTACKER ← planted by attacker no valid signature

Illustrative simulation. The live attack against a real running gateway is the AAI03 card in the OWASP coverage page.

No new runtime component. The signing key lives inside the existing capability-token trust boundary; the install story stays "deploy one binary." No PII enters the gateway. Memory content stays on the customer's memory store; the gateway only verifies signatures over content the agent presents on each call.

Learn more about memory provenance →  ·  See AAI03 coverage and live demo →  ·  Technical reference (cryptographic primitives, wire format) →

Capability inventory

What the gateway does

Grouped by what an enterprise security team asks about in the first thirty minutes of evaluation. Every item below is in production code today; clone the gateway from the open-source repos and run it in your own environment.

Identity & access

  • OIDC SSO (Okta, Entra, Auth0, Keycloak)
  • SCIM 2.0 provisioning
  • Viewer / operator / admin RBAC
  • TOTP step-up authentication
  • JIT admin elevation lifecycle

Authorization pipeline

  • Five-check pipeline (identity, capability, intent, policy, budget)
  • Capability tokens with cryptographic attenuation
  • Approvals queue with step-up gating

Audit & evidence

  • Tamper-evident per-tenant audit chain
  • /audit/verify dashboard
  • CSV / NDJSON export

Policy authoring

  • AI-assisted Rego (draft, dry-run, promote, rollback)
  • Multi-tenant policy scoping
  • Hot-reload, no gateway restart

Integrations

  • SIEM: Splunk, Datadog, Sentinel, S3, webhook
  • Slack / Teams / PagerDuty notifications
  • Native Athena DDL + KQL pack
Architecture

Where everything runs

Self-hosted, open core, runs entirely in your environment. The gateway is the only component on the agent's hot path. The console talks to the gateway's admin API. SIEM forwarders and notification receivers fan out from the audit pipeline; they never block the authorization decision.

            ┌─────────────┐
            │   Agents    │  (your apps; LangChain, AutoGen, custom)
            └──────┬──────┘
                   │ MCP / HTTP + capability token
                   ▼
            ┌─────────────┐         ┌─────────────────┐
            │  IntentGate │────────▶│  Extractor      │ (optional intent
            │  Gateway    │         │  (optional)     │  classifier)
            │             │         └─────────────────┘
            │  • Cap chk  │
            │  • Intent   │         ┌─────────────────┐
            │  • Policy   │────────▶│  Rego policy    │ (your decisions)
            │  • Budget   │         │  (Postgres)     │
            └──┬──────┬───┘         └─────────────────┘
               │      │
       allowed │      │ audit + notify + SIEM
               ▼      ▼
        ┌──────────┐  ┌─────────────────────────────────┐
        │ Upstream │  │  Audit chain (Postgres)         │
        │ tool     │  │  Webhook  (Slack/Teams/PD)      │
        │ server   │  │  SIEM     (Splunk/Datadog/Sentinel)
        └──────────┘  └─────────────────────────────────┘
Stack

How it's built

Engineering choices a security-minded buyer can verify. Memory-safe languages, standard protocols, mainstream dependencies, signed supply chain. No magic. No proprietary databases. No custom crypto.

Gateway · intentgate-gateway

Go 1.25, single static binary

Memory-safe, race-free authorization on the agent's hot path. Embedded Open Policy Agent for Rego evaluation. net/http + Go 1.22's ServeMux for routing — zero web-framework dependencies. Distroless container base (gcr.io/distroless/static); the running image ships only the binary and CA certs, nothing else for an attacker to land in.

Image: ghcr.io/intentgate-app/intentgate-gateway:1.7.1 · multi-arch (amd64, arm64) · signed with cosign · SBOM and provenance attestation attached at release.

Console Pro · intentgate-console-pro

Next.js 16, React 19, TypeScript

Server Components + Server Actions; admin tokens stay server-side and never reach the browser. NextAuth v5 for OIDC with any standards-compliant IdP. shadcn/ui components with a branded sky-blue palette. State persisted in Postgres alongside the gateway.

Strict TypeScript. ESLint on every push. Sensitive payloads (TOTP secrets, notification webhook URLs) AES-256-GCM encrypted at rest with a customer-supplied key.

SDKs

Python & TypeScript, zero runtime deps

Python: pip install intentgate · Python 3.10–3.13 · published to PyPI via OIDC trusted publishing (no API tokens in the release pipeline).

TypeScript: npm install @intentgate-app/intentgate · Node 18+ · dual ESM/CJS · zero runtime dependencies · byte-compatible capability attenuation with the Python SDK.

Both SDKs ship typed clients, capability attenuation (attenuate()), and a thin transport layer wrapping the gateway's MCP-compatible HTTP API.

State & persistence

PostgreSQL 14+, idempotent migrations

One Postgres instance backs revocations, audit events, the per-tenant hash-chain heads, the approvals queue, policy drafts, SCIM records, elevation rows, and notification-channel configs. No proprietary stores. No second database. Schema migrations run automatically at startup and are idempotent — restarting against an already-migrated database is a no-op.

Compatible with any managed offering: RDS, Cloud SQL, Azure Database, Aiven, Supabase. Self-hosted is fine too.

Packaging & deployment

Helm chart, OCI registry

oci://ghcr.io/intentgate-app/charts/intentgate · deploys gateway + extractor + Postgres-backed audit in one helm install. Values cover ingress, TLS, replica counts, resource limits, secret indirection (Vault, External Secrets Operator), and per-tenant admin-token wiring.

Verified against EKS, GKE, AKS, OpenShift, Rancher, and k3s. Docker Compose path supported for development.

Observability

Prometheus, OpenTelemetry, JSON logs

Per-check decision counts, per-stage latency histograms, upstream-call duration, and revocation lookups exposed on /metrics. Disciplined cardinality — no per-tool, per-agent, or per-JTI labels — so metrics scale with the deployment, not with traffic.

OTLP-over-gRPC tracing via the standard OTEL_EXPORTER_OTLP_ENDPOINT env. Spans cover the full request: per-check timings, upstream-forward, revocation lookup, audit-chain insert. Honors OTEL_* samplers and resource attributes.

Standards

Standards, not formats we invented

Identity: OIDC, SCIM 2.0.
Policy: OPA Rego.
Audit format: OCSF-aligned event shape with stable schema versioning and per-event hashing (SHA-256(prev_hash || canonical_event_json)).
Tool protocol: Model Context Protocol on the agent-facing endpoint.
Token format: signed capability tokens with caveat attenuation (Macaroon-inspired; not Macaroon-compatible by choice — the gateway issuer is the trust root).

Supply chain

Signed releases, SBOMs, OIDC publishing

Every gateway image is signed with cosign on release. SLSA build provenance attestation attached at release. SBOM (SPDX-2.3) included with each image — useful for procurement's "what's in your container" questions and for downstream vulnerability scanning.

PyPI and npm releases go through OIDC trusted publishing — no long-lived API tokens in CI. Each release derives from a specific Git tag, signed off by GitHub Actions identity. Sources on GitHub.

Performance: the gateway has been benchmarked at 2,000 requests per second at p99 = 1.5 ms on a single replica on a developer laptop (M-series Mac). Scales horizontally — replicas share the Postgres revocation and audit stores and don't coordinate on the hot path beyond the per-tenant hash-chain head row lock.

Day-1 to Day-2

What the operator workflow looks like

Day-1 — install + first decision

Two containers, one database, helm install. Wire OIDC, mint your first capability token, point one agent at the gateway. Write the initial Rego policy in the console; dry-run it against captured traffic before promoting. Configure Slack + PagerDuty notifications.

"Time to first deny in production: under one week."

Day-2 — running it

Operators don't hold standing admin. When they need it — rotating a policy, clearing a stuck token — they request JIT elevation with a reason, an admin approves through TOTP, role auto-upgrades for the window, every privileged operation in that window is auditable back to the approval. On expiry the role reverts.

"Every quarter the auditor asks for the chain-verified export. One click, done."

Read the deployment runbook →

Ready for a deeper look?

Discovery call is 30 minutes. We bring the demo; you bring your actual authorization questions.

Start the conversation