Machine access. Human-grade governance.
OAuth 2.0 client_credentials access for pipelines, services, and agents — scoped, rate-limited, and governed by the same policy engine as every interactive session.
Any service that calls AI models
From one-shot pipeline jobs to long-running autonomous agents — every machine caller gets its own identity and policy scope.
CI/CD Pipelines
Automated testing and deployment workflows that call AI models directly — without a human in the loop. Each pipeline gets its own client ID, scoped to the exact capabilities it needs, with rate limits that prevent runaway costs from a broken test loop.
Backend Services
Microservices and batch jobs that call AI models as part of their normal operation — content enrichment, classification, summarization. Each service authenticates with its own credentials and is governed by the same policy engine as interactive sessions.
Automated Agents
Autonomous AI agents that chain model calls across a multi-step workflow. Agent credentials carry explicit scopes — an agent authorized for summarization cannot silently escalate to code execution. Every hop in the chain is logged.
OAuth 2.0 Client Credentials
Service-to-service authentication via the OAuth 2.0 client_credentials grant. No user session required — each client authenticates with its own client ID and secret and receives a scoped JWT access token. Tokens are short-lived and automatically rotated.
Scope-Based Access Control
Each client is issued a specific set of scopes — the exact capabilities it needs and nothing more. A client scoped for read-only summarization cannot invoke DLP override policies or access admin endpoints. Scopes are enforced at the gateway before any model call is made.
Per-Client Rate Limits
Set independent rate limits and budget caps per client — separate from the org-level limits that govern interactive users. A batch processing job can be given a high request budget while a test pipeline is capped at a small fraction of that, without affecting production traffic.
DLP and Policy Enforcement
Machine traffic passes through the same 3-tier DLP pipeline and policy engine as interactive sessions. Automated agents cannot bypass content inspection or compliance controls — governance applies regardless of whether the caller is human or machine.
Full Audit Trail
Every M2M request is captured in the tamper-evident audit log with the client ID, granted scopes, policy decisions, and enforcement actions. Machine access is fully auditable — compliance teams can trace any automated AI call back to the originating service.
Tenant Isolation
M2M clients are scoped to a tenant — a service in tenant A cannot access models or data belonging to tenant B, even if both share the same gateway deployment. Tenant boundaries are enforced at the credential level, not just at the application layer.
RS256 Token Signing
Access tokens are signed with RS256 — industry-standard RSA asymmetric signing. The private key never leaves the Arbitex signing infrastructure. Downstream services verify tokens using the published public key, without sharing any secrets.
JWKS Endpoint
A standard JSON Web Key Set endpoint provides public keys for token verification. Any service can automatically retrieve the current signing keys at startup — no manual key distribution, no shared secrets, no out-of-band key exchange.
Zero-Downtime Key Rotation
Signing keys are rotated automatically using `kid` (Key ID) headers. Multiple keys are published simultaneously during rotation windows — services continue to validate existing tokens while seamlessly adopting the new key. No planned maintenance, no forced client re-authentication.
How it works
Register a client and issue credentials
Create an M2M client in the Arbitex admin console. Assign scopes, set rate limits and budget caps, and issue a client ID and secret. The client is ready to authenticate immediately — no additional deployment steps.
Service authenticates, receives a JWT
The service exchanges its client credentials for a short-lived JWT access token via the OAuth 2.0 token endpoint. The token carries the granted scopes and tenant context. Tokens expire automatically and are refreshed by the client as needed.
Requests flow through the full governance stack
Every call made with the token passes through DLP inspection, policy enforcement, and credential intelligence checks — identical to interactive user traffic. Enforcement actions and policy decisions are written to the audit log with the client ID attached.