Download the PHP package agentadmit/agentadmit-sdk without Composer

AgentAdmit SDK for PHP (Laravel)

User-mediated AI agent authorization. Plug-and-play for any Laravel app.

Get started: Sign up at agentadmit.com → Get your test keys → Install the SDK → Build. Test keys are available immediately after signup. Live keys become available when you subscribe an app.

Quick Start

Add your credentials to .env:

Add scope enforcement to any route:

Your app now supports AI agent connections with:

• Scoped access control (you define the scopes)
• User-controlled connection duration
• Token generation and exchange
• Mandatory introspection (every agent request validated through AgentAdmit)
• Revocation and remote audit logging (via the AgentAdmit hosted service)

How It Works

1. User clicks "AgentAdmit" in your app
2. Selects scopes and connection duration
3. Gets a token to give to their AI agent
4. Agent exchanges the token for scoped API access
5. User revokes anytime

The token goes to the human, not the agent. No automated delivery = no prompt injection surface.

Important

Mandatory introspection. All token validation goes through api.agentadmit.com. There is no self-hosted mode. No local JWT validation. No bypass. This is required for security, audit logging, and scope enforcement.

Admin revocation. As the app operator, you can revoke any user's agent connection by calling TokensClient::revoke($connectionId) from your backend (requires your operator API key).

Embeddable admin panel. Drop the <AgentAdmitAdminPanel> React component into your admin section to view all agent connections, usage metrics, billing status, and revoke any connection without leaving your app. See the React SDK for details.

In-app AI scopes. If your app has built-in AI features (analysis, plan generation, photo recognition), do not expose those as agent scopes. The user's AI agent can read the raw data and do the analysis itself. Exposing in-app AI endpoints to agents creates double cost.

Consent Ledger (Caller-Identity Consent)

AgentAdmit can host per-user consent switches for three independent caller classes: human_session, in_app_ai, and external_agent. No class's setting implies another's.

External agents: the verify result already carries the verdict:

consentGranted() fails closed when the verdict is absent (the hosted service omits it while its consent store is unreadable). To keep serving during that degraded mode, resolve an absent verdict authoritatively with ConsentClient::checkConsent($result->userId, 'external_agent') — the CallerConsent middleware does this for you.

Human sessions and in-app AI never hold AgentAdmit tokens, so ask directly:

Consent is orthogonal to revocation: a denied verdict means your app returns its own 403; the connection and token stay valid so the user can flip consent back on without re-connecting. Write switches through PUT /api/v1/consent/settings from your backend; export the audit trail with GET /api/v1/consent/export (every plan).

One-middleware drop-in. Instead of wiring the three paths by hand, the agentadmit.caller_consent middleware classifies the caller from the credential and evaluates the right independent path:

External agents are checked via hosted introspection (consent verdict plus scope); in-app AI via the Consent Ledger (fail closed); the human path defers to your own permission model unless caller_consent.gate_human is true. It is a consent gate, not an authenticator, so register it after your own authentication.

Presence Verification (WebAuthn Step-Up)

AgentAdmit can require the human behind a connection to complete a WebAuthn presence ceremony on the consent page. The verify result carries the outcome as an additive presence block, and the SDK surfaces it next to the consent verdict:

Or enforce it per route with the fail-closed middleware:

presenceVerified() is strict: it returns true only when the platform reports verified: true. Connections minted without a ceremony, malformed blocks, and older servers that omit the block entirely all count as not verified, so guarded routes return a 403 with error: presence_required. Unlike consent, absence does not mean allowed: presence fails closed because a missing block means no ceremony was ever proven.

Declared Purpose

Declared purpose: the user-facing reason recorded on the grant at the consent moment. Review-time record only, never an enforcement input; authorization decisions ride scopes, connection status, and consent.

Pass an optional purpose (max 300 characters) when issuing a connection token. AgentAdmit shows it to the human on the consent page ("Declared purpose: …"), records it on the grant, stamps it into every audit log row, and returns it from /verify introspection:

The SDK rejects purposes longer than 300 characters client-side with an InvalidArgumentException; when you pass no purpose, the field is omitted from the request entirely.

On the verify side, the result carries the nullable purpose for display and review:

purpose is null for connections minted without one and on older servers that omit the field. Do not branch authorization on it - /verify never gates on the purpose, and neither should your app.

User-Declared Intent

User-declared intent: the user's own words, typed by the human at the consent moment. It is distinct from purpose - purpose is the app's words, user_intent is the user's. Like the declared purpose, it is a review-time record only, never an enforcement input; authorization decisions ride scopes, connection status, and consent.

Pass an optional user_intent (1-300 characters) when issuing a connection token. It flows exactly like the declared purpose: recorded on the grant, returned from /verify introspection, stamped into audit log rows, and carried on ledger events. When the hosted presence ceremony runs, the user-declared intent is included in the verifiable-consent-evidence commitment.

Outbound validation mirrors purpose: a user_intent longer than 300 characters, or any non-string, non-null value, throws InvalidArgumentException client-side before any request is sent - the user's own typed words are never silently discarded. null and the empty string are simply omitted from the request. (Verify-side parsing stays tolerant: a malformed user_intent in the /verify response is normalized to null, never a failure.)

On the verify side, the result carries the nullable user-declared intent for display and review:

userIntent is null for connections minted without one and on older servers that omit the field. Do not branch authorization on it - like the purpose, /verify never gates on it, and neither should your app.

App-Attested Presence

If your app gates token minting behind its own embedded passkey/WebAuthn ceremony, AgentAdmit never witnesses that ceremony (it is origin-bound), so by default the hosted service reports presence.verified: false for those connections. Attest the ceremony fact at issuance to close that gap - AFTER verifying and consuming your own fresh, purpose-bound attestation:

The SDK sends it as presence: {verified: true, uv: true, method, verified_at} - verified/uv are literal true by construction and the class cannot represent anything else. The hosted service validates freshness (10-minute window, 60 s future clock-skew slack) and stores the method provenance-marked app:<method> so app-attested facts stay distinct from ceremonies AgentAdmit witnessed itself. Introspection, the grant-event ledger, and the evidence API then carry presence.verified: true for the connection.

Honesty ceiling: this is your app's attestation, recorded and provenance-marked. It is not witnessed by AgentAdmit and not independently verifiable. Only attest a ceremony that verified the user with UV (biometric or PIN user verification); a ceremony without UV carries no presence fact, so pass null (the default). An out-of-contract method (^[a-z0-9_]+$, 1-60) throws InvalidArgumentException at construction, before any request; verified_at serializes RFC 3339 with an explicit offset because DateTimeInterface always carries a timezone.

Per-Call Audit Telemetry

Every verified call reports what it actually exercised. On each introspection the SDK sends, alongside the token, the scope the middleware enforced for that call (scope_used), the request path (endpoint), and the HTTP method (method), and the hosted service records them in the app's tamper-evident audit log — so an audit row answers "which scope, which endpoint, which method" per call, not just "a token was checked".

The scope middlewares (agentadmit.scope, agentadmit.scope_if_agent) report all three automatically — the middleware parameter is the enforced scope:

agentadmit.presence reports endpoint and method only. agentadmit.caller_consent:<scope> reports all three and sets the hosted consent-first guard automatically, so denied caller classes receive no scope-state disclosure. Direct client calls send whatever you provide — every telemetry argument is optional and the signature stays backward-compatible:

Honesty rules:

• Omitted means omitted. A field that is not known is left out of the request entirely (never null or an empty string), and the hosted audit row honestly records it as "not reported" rather than inventing a value.
• No query strings. The endpoint is the path only - the SDK strips everything from the first ? or # client-side before sending, because query strings can carry PII. Paths are truncated to 500 characters; methods are uppercased and capped at 20.
• scope_used is the single declared scope the integration point enforced for that call, never a joined list of everything granted.

Hosted refusals fail closed

As of 1.10.0 the SDK also treats an active: true introspection response that carries a string error field as a refusal of that call, never a pass-through:

• insufficient_scope → the middleware returns 403 {error, required_scope, granted_scopes} (the standard step-up shape).
• bound_exceeded → 403 with the hosted error_description, bound, and renewal fields passed through verbatim (the connection's bounded capability is exhausted; the token itself stays valid).
• Any refusal code this SDK version does not recognize → 403 {error: <code>, error_description: "Call refused by the authorization service."} — unknown hosted verdicts never become an allow.

IntrospectionClient::verify() surfaces these as VerificationDeniedException (a 403 AgentAdmitException subclass); getDenialBody() is the exact JSON body the middlewares return.

Rate Limiting

The AgentAdmit introspection endpoint enforces rate limits. The PHP SDK handles HTTP 429 responses automatically with exponential backoff and jitter - no changes needed in your middleware code.

Retry behavior

The SDK also respects the Retry-After response header - if present, it overrides the computed backoff delay.

Configuring max retries

In config/agentadmit.php or .env:

Handling exhausted retries

When all retries are exhausted, IntrospectionClient::verify() throws RateLimitException:

RateLimitException methods:

• getRetryAfter() - seconds from Retry-After header (null if absent)
• getLimit() - X-RateLimit-Limit header value (null if absent)
• getRemaining() - X-RateLimit-Remaining header value (null if absent)
• getReset() - X-RateLimit-Reset Unix timestamp (null if absent)

Documentation

Full integration guide: https://agentadmit.com/docs/app-owner-guide

Data Collection & Privacy

The AgentAdmit PHP SDK runs server-side and does not interact with app stores or end-user devices directly.

What the SDK does

• Validates AgentAdmit tokens by calling AgentAdmit's hosted introspection endpoint (https://api.agentadmit.com/api/v1/verify) on every agent request - this is mandatory introspection; there is no local or offline validation mode
• Enforces scope-based access control on your API routes
• Manages connection lifecycle (issue, exchange, revoke) via the AgentAdmit hosted service

What the SDK does NOT do

• Does not transmit raw end-user PII (such as name, email, or device identifiers) - each introspection request sends the opaque access token, your API key, and the per-call audit telemetry described above (the enforced scope, the request path with the query string stripped client-side, and the HTTP method)
• Does not perform passive background telemetry or analytics - network calls occur only during active token validation
• Does not maintain its own persistent storage; connection state and audit logs are held by the AgentAdmit hosted service

What the AgentAdmit hosted service records

On every token validation, AgentAdmit's /api/v1/verify endpoint receives the access token and API key, resolves the token to its user_id, connection_id, granted scopes, and agent_label, and records per-call metadata (including the endpoint and timestamp) for billing, audit logging, the security alerts engine, and usage metering. This is integral to how AgentAdmit works and applies to both test and live keys. See the "Mandatory introspection" notes above and the compliance guide for the full data-handling description.

Privacy impact

Since this SDK runs on your server, it has no direct App Store or Play Store compliance surface. Your client-side integration (e.g., the AgentAdmit React SDK) handles privacy manifest and data safety requirements.

For complete compliance guidance, see our compliance guide.

License

All rights reserved. Patent pending.

Security Alerts

Six alert type constants on AlertsClient.

Configure

List Events

Get Config

Notifying Your Users

AgentAdmit detects anomalies, fires alerts, and (with kill switch) auto-revokes connections. How you notify your own users is up to you. AgentAdmit provides the data - you deliver it through your own system (in-app notifications, email, push, etc.).

• Poll alerts - Use the SDK methods above from your backend to check for new events, then notify users through your existing system.

• Webhook delivery - Configure a webhook URL in your AgentAdmit dashboard. When an alert fires, AgentAdmit POSTs the payload to your server, signed with your whsec_… secret. The payload carries alert_id, alert_type, severity, the connection's agent_label, and the grant's declared purpose; the full shape is documented in the Webhook Delivery section of the MCP guide at https://agentadmit.com/docs/mcp-guide. Always verify the signature against the raw request body before trusting the payload:

  The header format is t=<unix_ts>,v1=<hex> - an HMAC-SHA256 of {t}.{rawBody} keyed with your signing secret. Verification uses hash_equals() (constant time) and rejects timestamps more than 5 minutes off (replay protection).

• React SDK - Embed the <AlertsPanel> component so users can view their own alert history and tighten thresholds.

Issuing & Exchanging Tokens