September 2026 Summaries

WorkOS provides a remote MCP server at https://mcp.workos.com/mcp and a CLI that simplifies configuring it for supported AI coding agents, currently Claude Code, Codex, and Cursor. After installing the standalone CLI through Homebrew, npm, or direct downloads, users can run `workos mcp install` to detect agents and add the server definition using each client’s appropriate configuration method, while optional `--agent` flags limit installation to selected clients. Configuration is separate from authentication: the CLI does not require credentials or inspect agent credential stores, and users must complete OAuth sign-in within each agent through WorkOS Connect. Status and diagnostic commands report whether clients are available and configured, although authentication remains unverified, while JSON status output and `workos doctor` can identify endpoint mismatches. Installation is opt-in, can be removed safely with `workos mcp remove`, and includes safeguards for malformed Cursor configuration files, outdated client versions, existing conflicting Codex endpoints, and incomplete OAuth flows. The server supports additional clients through manual setup, operates under the user’s existing WorkOS permissions and selected environment, and can be restricted by administrators through enablement, production-access, and write-access controls.

RFC 9967, published in May 2026, defines a standards-track SCIM profile for Security Event Tokens (SETs) to make provisioning events more consistent across identity providers. It addresses common shortcomings of ad hoc webhooks, including incompatible payload formats, inconsistent retry behavior, uncertain ordering and duplicate handling, and provider-specific or absent integrity protections, by using signed JWT-based events with standard claims and registered event URIs. The RFC also extends SCIM ServiceProviderConfig so providers can advertise event support and introduces an optional asynchronous request mode that separates request acknowledgment from completion notifications. However, it does not prescribe an event transport, guarantee delivery, or require existing vendors to adopt the profile, meaning organizations must still handle event receipt and outages while supporting a mixed environment of SET-based events and legacy webhooks. Adoption is most useful when a provider already supports the standard or when a SCIM service provider wants to improve interoperability, while reliable existing webhook integrations need not be migrated immediately; the source also presents WorkOS Directory Sync as a service intended to absorb evolving provisioning-integration requirements.

AI agent access in SaaS applications requires controls that clearly establish an agent’s identity, whom it represents, its permission limits, and how its actions can be audited and revoked. The checklist recommends giving agents separate identities rather than user tokens, using short-lived audience-bound delegated tokens, and limiting delegated agents to the intersection of their own permission ceilings and the user’s current access. Authorization should be evaluated on every tool call, at the resource and tenant level, while retrieval systems must filter unauthorized data before it enters a model’s context. Sensitive or irreversible actions such as sending messages, exporting data, changing permissions, or making payments should require out-of-band, action-specific human approval, particularly when untrusted content could influence the agent. Teams should maintain dual-identity logs that record the agent, represented user, organization, target, decision, policy, and intent; apply rate limits, budgets, circuit breakers, and anomaly alerts; and provide customers with visibility into agent activity. Effective offboarding includes immediate cascading revocation for users, agents, tokens, sessions, and sub-agents, tenant- and agent-level kill switches, and regularly tested revocation drills. The material also identifies WorkOS products that can support these practices, including Agent Auth, Fine-Grained Authorization, Pipes Relay, Audit Logs, and Directory Sync.

Efforts to define how SCIM should represent AI agents have consolidated from competing Okta and Microsoft proposals in 2025 into a jointly authored June 2026 informational draft, draft-wzdk-scim-agent-resource-00, also involving Nextident. The earlier disagreement centered on whether agents should be modeled primarily through their relationship to an application or as independent, platform-neutral identity resources, while the emerging approach increasingly treats agents as distinct SCIM-managed identities with lifecycle, group, role, entitlement, and external-reference attributes. Working-group discussions have also clarified a boundary between public agent identities and ephemeral workload identities: SCIM is intended to provision and manage an agent’s eligibility for an identity, rather than issue runtime credentials or govern authorization directly. Under this layered model, OAuth and workload identity systems such as SPIFFE would provide scoped, short-lived access and credentials, while SCIM handles identity lifecycle and federation-related provisioning. Because the consolidated draft remains informational, unfinished, and scheduled to expire in December 2026 unless renewed or advanced, organizations are advised to avoid relying on it as a stable standard while considering agent identities as first-class resources rather than solely properties of applications.

JWT handling in Elixir can use OTP primitives to manage key caching, rotation, and refresh through supervised GenServers and ETS, while the JOSE, Joken, and JokenJwks libraries respectively provide low-level cryptography, an Elixir-oriented JWT API with claim validation, and JWKS retrieval and caching. The guide explains JWT structure, including readable but unencrypted claims and signatures that establish integrity, and demonstrates RS256 key generation, token creation, decoding for debugging only, and verification with local public keys or external JWKS endpoints. It recommends strict algorithm allowlists when using JOSE directly, validating expiration, issuer, and audience claims, and using Joken.Config modules to centralize token policy. For external identity providers, it outlines configuring JokenJwks as a supervised process that resolves keys by the token’s kid header, retains last-known-good keys during fetch failures, and limits refetches to reduce kid-flooding risks. It also presents Phoenix plugs for Bearer-token authentication and role authorization, alongside production guidance such as short-lived access tokens, runtime configuration, structured failure logging without token contents, and tests for invalid or tampered tokens. The text concludes by describing WorkOS as a service for enterprise authentication, SSO, directory management, and token issuance.

Ox Security’s report, “15,465 MCP Servers, 0 Governance,” examined three public MCP registries and found that registry listings generally provide little verifiable information about server authentication, authorization, ownership, lifecycle management, or data residency. Its survey of roughly 5,095 hostnames identified servers hosted outside the United States, unresolved domains that could potentially be re-registered by others, and some services operating from home networks or consumer tunnels, highlighting risks associated with changing infrastructure control. The report argues that these issues stem less from registry discovery practices than from MCP’s historically decentralized approach to identity and access control, in which individual server developers decide whether and how to protect tool discovery and calls. It points to emerging measures including Client ID Metadata Documents for verifiable client identity, enterprise-managed authorization through identity providers, agent-registration protocols for establishing user identity, and per-call runtime policy checks. A demonstration involving a malicious server posing as a code scanner showed how broad “always allow” permissions could permit later requests for sensitive files, although results varied by model and configuration. Overall, the discussion characterizes MCP governance as uneven rather than universally absent, with security depending on controls applied throughout an agent’s lifecycle.

JFrog disclosed two critical vulnerabilities in the open-source Bifrost AI gateway during September 2026, including CVE-2026-90898, which allowed unauthenticated attackers to execute arbitrary commands through a single request to an MCP client-registration endpoint. Both flaws stemmed from Bifrost shipping its management API with authentication disabled by default, while its Docker configuration could expose that API publicly when ports were published. The newer vulnerability executed an attacker-provided stdio command immediately when a client was registered, before any MCP handshake, capability negotiation, or authorization occurred. Although Bifrost version 2.1.0 added a setup token to protect initial administrative setup, the discussion argues that the broader issue is not an MCP protocol defect but insecure management-API design. It distinguishes Bifrost’s administrative client registration from OAuth Dynamic Client Registration and concludes that gateways require default authentication, authorization scoped to high-risk administrative actions, and policy checks that assess the potentially dangerous behavior requested before execution.

CoPhish, disclosed by Datadog Security Labs in October 2025, demonstrated how Microsoft Copilot Studio could be used to host OAuth consent phishing on a legitimate Microsoft domain, directing users to malicious app consent requests and silently exfiltrating resulting tokens through server-side workflow actions. The technique can affect ordinary users with permitted Microsoft Graph scopes as well as privileged administrators capable of granting broader permissions, while evading common defenses based on suspicious domains, certificates, browser traffic, and MFA. Its broader significance is that many agent builders, low-code automation tools, MCP marketplaces, and integration platforms share the same structural risk when they allow configurable login flows and automated post-consent actions under a trusted platform domain. Recommended safeguards include allowlisting redirect destinations, restricting and auditing post-authentication actions, using narrowly scoped audience-bound tokens, separating agent-building privileges from approval for sensitive scopes, and correlating agent creation with consent-grant events. Microsoft’s Entra Agent ID and WorkOS Agent Auth reflect a wider shift toward treating agents as distinct, auditable identities with short-lived and revocable permissions, though secure product design remains necessary to prevent consent traps from being created in the first place.

Version 2.1.0 of the official Model Context Protocol TypeScript SDK adds support for DPoP sender-constrained OAuth tokens and request-time OAuth scope challenges, implementing security measures from the 2026-07-28 MCP authorization specification. DPoP binds access tokens to a client-held key pair, requiring signed proofs on requests so stolen tokens cannot be reused without the private key; the SDK automates proof signing, nonce retries, and token-flow integration through a new OAuth client provider method and shared cryptographic helpers. Server packages now allow tools, resources, and prompts to issue HTTP 403 scope challenges before execution, with a requireScopes helper for static permissions and callbacks for conditional authorization. The release also adds Streamable HTTP limits for request body sizes and JSON-RPC batch lengths. MCP server operators are encouraged to evaluate DPoP support in their authorization systems and adopt narrowly scoped, on-demand permissions for sensitive actions rather than relying solely on broadly authorized bearer tokens.

ID-JAG, or Identity Assertion JWT Authorization Grant, is a proposed IETF OAuth mechanism for exchanging a short-lived, audience-specific signed assertion for another credential, rather than serving as an API access token itself. The same JWT type supports two distinct use cases: enterprise-managed authorization, where a company’s identity provider authorizes an AI client to access an MCP server under centrally managed SSO policy, and agent-verified registration, where an agent provider attests to a user’s identity so a service can provision or bind an account. Enterprise authorization relies on an existing mutual SSO trust relationship and redeems the ID-JAG directly for an access token, while registration relies on a curated provider trust list, verified contact information, recent authentication, and an intermediate service-signed assertion before token issuance. Their claims, validation requirements, provisioning models, and revocation mechanisms therefore differ despite sharing a token format. Organizations may need both integrations, while agent registration also has limitations when providers do not issue ID-JAGs, requiring alternatives such as user-confirmed flows; an unresolved issue remains around agents operating across both provider-based registration and enterprise policy environments.

User impersonation in token-based AuthKit applications differs from traditional cookie-session approaches because impersonation identity is embedded in signed credentials through an impersonator object and the access token’s act claim, allowing APIs to verify both the acting user and the administrator responsible. Successful setup requires configuring the WorkOS Initiate login URI to the application’s sign-in route so PKCE validation can proceed correctly after the dashboard redirect. AuthKit React exposes impersonator state directly, while AuthKit JS requires developers to retain it from both redirect and token-refresh callbacks, and mobile SDKs return it through the public PKCE authentication response. Client-side claim decoding is suitable only for display features such as an impersonation banner, while authorization and auditing must rely on server-side token verification. The recommended exit design keeps the administrator’s and impersonated user’s tokens separate, making termination a matter of discarding the impersonation token rather than restoring a client-stored identity, avoiding vulnerabilities common in cookie-based implementations. Impersonation sessions expire after 60 minutes, with browser logout used for voluntary session ending and the server-side revoke API used to terminate sessions remotely.

LiteLLM patched CVE-2026-59822 in version 1.84.0 after its MCP endpoint could treat failed key validation as a valid empty identity, allowing fabricated Bearer tokens to access tools; the high-severity flaw was later added to CISA’s Known Exploited Vulnerabilities catalog. The incident illustrates recurring MCP authorization weaknesses: authentication failures that fall back to permissive defaults, public-route checks that inspect attacker-controlled full URLs rather than normalized paths, forwarding client tokens to downstream services without validating their intended audience, and reliance on shared static keys that lack per-caller identity, scoped access, and selective revocation. MCP’s July 2026 authorization specification explicitly requires token validation, audience binding, RFC 8707 resource parameters, PKCE checks, and prohibition of inbound-token passthrough, favoring token exchange for upstream access. Organizations using affected LiteLLM versions should upgrade or block the MCP route, rotate accessible credentials, and assess their own servers for fail-open authentication, route-matching flaws, token audience validation, safe upstream delegation, and per-client revocation capabilities.

Critics argue that Model Context Protocol (MCP) servers often impose unnecessary token costs by loading tool schemas into model context and duplicating capabilities already available through command-line tools and documented APIs, making direct API access or code-generated calls more efficient in many cases. The passage contends, however, that removing MCP wrappers can also remove a publicly specified authorization boundary: MCP’s HTTP authorization model supports user-delegated, audience-bound, revocable tokens, resource discovery, restrictions on token forwarding, and auditable approval flows, whereas direct API use commonly falls back to long-lived environment-variable API keys that agents may access. Emerging approaches such as content negotiation and Web Bot Auth can improve machine-readable responses and verify an agent’s operator identity, but they do not by themselves establish human delegation or authorization. The author acknowledges that MCP authorization is optional, inconsistently implemented, vulnerable in some flows, and not a guarantee of granular consent, but argues that direct API architectures need equivalent protections regardless of protocol: credentials hidden from the model, audience-bound tokens, explicit and expiring user delegation, in-context consent mechanisms, and durable audit records.

WorkOS Airlock is presented as a framework for securing AI agents that access company data and perform actions such as sending emails by combining deterministic API-level permissions with runtime content and context evaluation. Fixed rules should govern clearly defined operations, such as allowing draft deletion while blocking deletion of received mail, using default-deny behavior and carefully avoiding overly broad grants. Runtime checks address cases where identical operations differ in risk based on message content or historical context, such as detecting financial data in an email or determining whether a distribution list has previously been used. Fixed denials and approval requirements take precedence over runtime judgment, and failed required evaluations result in denial. The approach recommends controlled testing of both layers, including prohibited operations, sensitive content written in varied formats, configuration changes, and attempted policy overrides, while noting that successful tests cannot guarantee complete detection of disclosures or prompt-injection attacks.

WorkOS Airlock is an early-access authorization layer designed to govern AI agent actions across connected business systems by evaluating proposed API calls against declared intent and organizational policies. In the Agent Night demonstration, Airlock sat between an agent and WorkOS Pipes connections to Linear and Gmail, allowing the agent to read planning issues and send emails without exposing provider credentials or granting unrestricted use of broad account permissions. Intent supplies task context, while policies define enforceable limits on operations, recipients, and content; natural-language policies can be converted into fixed API rules and runtime checks, including checks against contextual data such as mailbox history. In the demo, Airlock allowed a routine planning update, blocked an email that would disclose token-spend figures under a financial-data policy, and required IT administrator approval for a previously unused distribution list. Organizations using this model are advised to route all required actions through Airlock, avoid giving agents direct provider credentials that could bypass controls, and test both permitted and prohibited workflows while independently verifying provider outcomes and the accuracy of agent-generated content.

GitLab.com will introduce subscription-tier-based rate limits on October 19, 2026 for Free users and unauthenticated traffic, followed by Premium and Ultimate customers in January 2027, with trial enforcement windows on October 7 and 14 intended to help users test automation. Unauthenticated requests will be restricted to 60 per hour per IP address, while authenticated users will receive hourly limits of 5,000, 15,000, or 25,000 requests for Free, Premium, and Ultimate tiers respectively, alongside burst limits and existing endpoint-specific restrictions. The change primarily affects heavily automated workloads, especially scripts and agents that do not send credentials, since paid subscriptions do not apply unless each request is authenticated. GitLab recommends using tokens, service accounts for distinct non-human workloads, request batching and caching, monitoring rate-limit headers, and honoring 429 retry instructions with backoff logic. Although GitLab says most ordinary browsing, Git activity, and CI usage should remain unaffected, critics argue that strict per-IP anonymous limits may disproportionately affect public open-source projects and organizations sharing network addresses while sophisticated scrapers can rotate IPs. The policy reflects a broader industry shift toward metering platform capacity based on authenticated identity, similar to approaches used by GitHub and Docker Hub.

Access-token permissions are signed snapshots of a user’s organization-specific role at the time of issuance rather than live authorization decisions, so role or permission changes generally take effect only after token expiration or an explicit session refresh, while organization membership deactivation revokes sessions immediately. Applications should distinguish a session with no selected organization, which requires organization selection, from an empty permissions array, which represents a valid role with no granted capabilities. Switching organizations requires a new token and may trigger reauthentication for SSO or MFA, and servers must authorize each request using the newly supplied token rather than cached decisions. Permission checks establish general capability but do not establish access to a particular record, so data-layer queries must enforce ownership using the signed organization ID from token claims instead of caller-controlled request parameters. Permissions, billing-derived entitlements, and targeted feature flags may appear similarly in tokens but serve distinct purposes and share token staleness constraints. Because JWT size is limited and cached claims can become outdated, frequently changing, resource-specific, or large-scale authorization decisions should be evaluated through runtime authorization checks. Authorization should rely on stable permission slugs rather than role slugs, since role meanings, custom role identifiers, and role assignments can change across organizations.

Voice agents that narrate and execute background tool calls create authorization risks because they control both the audio presented to users and the speech they interpret, leaving no independent channel to verify consent or identity. Spoken approvals are not reliably bound to exact tool arguments, can occur after execution has already begun, and remain vulnerable to cloned speech, ambiguous narration, language differences, and model classification errors; deepfake detection can identify synthesized audio but cannot establish account ownership. The text argues that voice confirmation should therefore be limited to reversible, low-impact, low-sensitivity actions such as drafting replies or placing calendar holds, while money movement, access changes, data deletion, and broad communications require approval through a separate authenticated device or interface. It recommends binding approvals to hashes of exact arguments, enforcing independent policy and freshness checks rather than relying on model judgment, and expanding audit logs to capture the narration heard, argument hashes at approval and execution, execution timing, and retained or signed audio evidence. Although second-device escalation undermines hands-free convenience, the account maintains that this friction is necessary for high-risk actions as voice use expands and protocol support for secure reauthorization remains incomplete.

Non-human identities, including service accounts, API keys, integrations, and AI agents, are becoming a major security governance challenge because organizations often lack a complete inventory, clear ownership, lifecycle controls, and regular access reviews for them. Unlike employees, these identities do not have HR-driven onboarding and offboarding events, can proliferate through integrations and agent-created sub-agents, and often retain broad, long-lived permissions that increase breach risk. SCIM can help manage the lifecycle of relatively stable machine identities by standardizing provisioning, deprovisioning, directory synchronization, ownership, and group-based categorization, but it does not natively support fine-grained, temporary permissions, credential rotation, or a mature distinct identity model for AI agents. The text argues that SCIM should be combined with technologies such as SPIFFE for verifiable short-lived workload identities and OAuth for scoped, time-limited authorization. Organizations are encouraged to assess whether they can monitor non-human identities in real time, automatically expire access, include them in access reviews, and revoke credentials for retired systems, then apply the same lifecycle discipline used for human users.

A practical AI email-agent pilot should test whether an agent can complete routine work safely and with meaningful time savings, rather than simply shifting effort to human approval queues or risking confidential disclosures. Using a workflow that reads Linear planning issues and emails a manager, organizations should define success criteria, use test accounts and controlled recipients, route provider calls through WorkOS Airlock with policy enforcement, and keep direct credentials inaccessible to the agent. The evaluation should cover successful routine emails, blocked attempts to send prohibited financial information, and approval requirements for unfamiliar distribution lists, while confirming actual delivery in Gmail rather than relying only on authorization logs. Testing should also verify that pending or rejected approvals do not permit sends and that approvals cannot be reused for modified requests. Teams should compare total human review, correction, recovery, setup, model, and service costs against manual completion time, tracking both active effort and elapsed approval delays. Expansion is appropriate only when routine work is accurate, policy violations are reliably stopped, approvals work as intended, and the remaining oversight effort produces worthwhile savings.

AI agent credential systems are evolving across several layers of the stack, with Google Managed Agents and NVIDIA OpenShell keeping secrets outside sandboxes through proxies and placeholder credentials, Rubrik Agent Identity issuing narrowly scoped tokens for individual tool calls, Microsoft’s Global Secure Access firewall inspecting remote MCP protocol traffic, and Opal Zero evaluating requests before delegating enforcement to existing gateways. These approaches address different risks, including credential theft, standing privilege, unapproved tools or servers, and permanent access grants, but each retains limitations such as overly broad credential scopes, gateway dependence, or incomplete coverage of local stdio-based MCP servers. The central distinction is that preventing an agent from exfiltrating a secret does not itself restrict what the agent can do with that secret, leaving prompt-injection and confused-deputy risks when broad credentials are accepted for allowlisted destinations. The analysis argues that durable authorization requires short-lived, audience-bound, scoped tokens issued by an authorization server and validated directly by MCP resource servers, while proxies, gateways, and protocol firewalls provide complementary containment and enforcement layers rather than replacements for resource-level authorization.

Enterprise Managed Authorization using ID-JAGs creates a difficult account-resolution problem because a cryptographically valid token can identify an enterprise subject without proving that it corresponds to an existing local user, particularly when browser-based confirmation and inbox verification are unavailable. The draft permits optional email-based resolution and just-in-time provisioning but does not define an email_verified claim, so email matching represents trust in an enterprise IdP’s provisioning practices rather than verified ownership and should not silently merge with an existing account by default. Safer resolution prioritizes aud_sub, which identifies the user in the resource server’s namespace when present, followed by a tenant-scoped federated identity key of issuer, tenant, and subject, then correctly scoped SAML sub_id data, and finally email under explicit per-issuer policy. Multi-tenant issuers require tenant as part of the identity key, tenant scope should come from local issuer configuration rather than token claims, and sub_id.issuer must never be used to establish trust before full token validation. The text distinguishes relatively low-risk provisioning of a new unmatched user from the higher-risk adoption of an existing account with the same email, recommending refusal or administrator review for unresolved or risky links, along with a visible reconciliation queue and audit trail.

AI agents challenge traditional authorization models because their required access can emerge unpredictably during a task, creating a tradeoff between overly narrow permissions that halt work and broad standing access that increases risk. Role-based access control (RBAC), attribute-based access control (ABAC), and relationship-based access control (ReBAC) remain effective for organizational roles, contextual conditions, and resource-specific sharing, respectively, but each relies on permissions being knowable before execution. Intent-based access control (IBAC) addresses this gap by assessing whether an agent’s requested action aligns with its current task, potentially allowing, denying, escalating, or requesting clarification. The term IBAC has been used in several earlier contexts and now encompasses both inferred approaches, which use models to judge actions dynamically, and declared approaches, which enforce predefined scopes deterministically. Effective implementations may combine both approaches, enforce controls close to agents and service APIs, broker credentials so agents cannot bypass controls, and preserve auditable records. IBAC is presented not as a replacement for existing authorization systems but as an additional layer that narrows an agent’s access within the boundaries established by RBAC, ABAC, and ReBAC.

SCIM directory Logs provide customers with self-service visibility into provisioning activity that previously required support engineers to inspect server logs, addressing common cases where users fail to appear or access an application after identity-provider changes. The dashboard retains 30 days of IdP provisioning requests, including request and response payloads, statuses, client details, identifiers, timestamps, and actionable debug messages for failures. Filters by action, status, method, email, external ID, group, and precise time ranges help administrators isolate relevant events quickly, while bidirectional links between provisioning requests and WorkOS events allow investigations to begin from either the triggering IdP request or its resulting user or group change. By pairing raw protocol details with explanations of likely configuration fixes, the feature aims to reduce support delays and help customers diagnose SCIM issues independently.

At a New York fireside chat, Gergely Orosz and Michael Grinich discussed how AI is changing software engineering by introducing probabilistic model output as a second “material” alongside deterministic code, requiring engineers to balance reliability, cost, latency, and architectural choices. They argued that AI tools have raised overall productivity enough to reduce the advantage of individual early adopters, but have also enabled teams to pursue larger migrations and more ambitious projects while human coordination and customer-change constraints remain. The conversation described a weakening of traditional specialization boundaries among individual contributors, with product and platform engineering emerging as broader roles, while increased engineering throughput may create greater demand for technically capable product managers. Grinich said companies may need to build temporary internal agent tools to understand frontier capabilities, and both speakers emphasized that AI reliability depends on preexisting practices in testing, review, ownership, and observability rather than on adding agents alone. They also examined agent-first products, including machine-readable registration, temporary anonymous accounts, and constrained access models, arguing that businesses should serve agents as a new consumer class without abandoning human interfaces. Orosz concluded that engineers should seek demanding environments that build durable experience, support internships and entry-level opportunities, and recognize that AI is likely to shift engineering work rather than eliminate it, as organizations continue to build and rebuild systems using both deterministic and probabilistic components.

MCP server tool definitions create recurring token, latency, and accuracy costs because they remain in the model’s context on every turn, with Anthropic estimating that a typical five-server setup can consume about 55,000 tokens before a task begins and noting that tool-selection performance declines beyond roughly 30 to 50 available tools. Large intermediate data exchanged between direct tool calls further increases token use, can exceed context limits, and may introduce copying errors, so exposing a REST API’s many granular endpoints directly to agents is often inefficient. The recommended approach is to design a smaller, outcome-oriented tool surface that combines underlying API calls into common workflows, then use deferred loading and tool search for larger catalogs so the model loads only relevant definitions. For workflows involving large documents or datasets, code execution can keep data inside a sandboxed environment rather than routing it through the model context, though it requires operational safeguards. Servers can also reduce reconnect overhead by providing deterministic tool-list ordering and sensible catalog cache TTLs under the 2026-07-28 MCP revision, while newer headers support per-tool routing, metering, authorization, and rate limiting.

Agent Auth, now in early access, aims to make automated actions visible in systems where agents often operate through shared accounts or borrowed user sessions, causing audit logs to incorrectly attribute software actions to people. Its agent access tokens are JWTs verified through existing user-token infrastructure but include a `sub_profile` claim set to `ai_agent`, allowing applications to distinguish agents from users reliably without maintaining identifier lists. Agent tokens separate the acting agent instance in `sub` from the delegating user in `act.sub`, enabling audit trails to record both the actor and the authority, while autonomous agent sessions have no delegated user. The recommended approach is to preserve agent-related details such as caller type, authorizing user, session, and declared intent in audit-log metadata; intent is useful context but is not verified evidence of an action’s purpose. Lifecycle webhooks and Events API events for agent blueprints, instances, and sessions provide visibility into agent creation, configuration, use, and revocation, while separating agent traffic from user traffic enables monitoring of automated write activity, permission denials, session behavior, and actions tied to inactive delegating users.

The Agentic AI Foundation and Linux Foundation Education introduced the vendor-neutral Model Context Protocol Associate certification on September 14, 2026, based on the MCP 2026-07-28 specification, with security and governance comprising 24% of its 90-minute online multiple-choice exam. The security material emphasizes trust boundaries, audience-bound access tokens that must not be forwarded to upstream APIs, per-tool authorization checks, explicit delegation, least-privilege permissions, and the distinction between requesting broader scopes and re-authenticating users. It also covers human approval, time-limited session authorization, the fact that tool annotations are advisory rather than enforceable controls, and transport-specific requirements such as using environment credentials rather than OAuth for STDIO implementations. Because the revised protocol is stateless, identity and authorization details must accompany each remote request, while meaningful auditability requires identifying the agent, delegating user, authorized scope, and approval context rather than merely recording actions. Candidates are encouraged to understand OAuth 2.1, PKCE, protected resource metadata, resource indicators, and the shift from Dynamic Client Registration toward Client ID Metadata Documents; the $250 certification is valid for two years and includes 12 months of eligibility and one retake.

MCP’s 2026-07-28 specification revision shifts the protocol to a stateless, HTTP-like model by removing protocol sessions, the initialize handshake, stream resumability, ping, and logging/setLevel, allowing requests to be handled by any server instance without sticky routing or shared session storage. Requests now carry protocol version, client capabilities, and identity metadata individually, while servers must support an optional server/discover endpoint; multi-step application state is expected to use explicit server-issued handles passed as tool arguments. The most consequential migration challenges are the loss of SSE stream resumption, which requires clients to retry failed requests and developers to add idempotency protections for side-effecting tools, and the replacement of server-initiated elicitation, sampling, and roots interactions with multi-round-trip requests where clients resubmit calls with collected input. The revision also introduces header-based method and tool routing, cache metadata for list and resource endpoints, subscriptions/listen for change notifications, revised errors, and formal feature deprecation rules. Roots, Sampling, Logging, HTTP+SSE, certain includeContext values, and OAuth Dynamic Client Registration are deprecated, while Client ID Metadata Documents, stronger OAuth issuer validation, and per-issuer credential binding are encouraged. Experimental Tasks has moved into an official extension, and updated Tier 1 SDKs support the revision while preserving compatibility with earlier versions.

Airlock is a standalone authorization system designed to govern AI agents’ actions across company tools by applying centrally managed policies beyond standard provider permissions. Demonstrated with a custom agent connected to Gmail and Linear, it allowed routine actions while blocking an email containing token-spend information classified as financial data and requiring IT approval for an unfamiliar distribution list. Agents retain responsibility for planning tasks and proposing tool calls, while Airlock evaluates those calls against organizational rules, task context, deterministic API-level restrictions, and runtime content checks before they reach connected services. Originally developed within the Atlas Slack-based AI coworker, Airlock was separated so its governance engine could support multiple agent interfaces and workflows, with activity records and Slack-based approval requests providing visibility and human oversight. The product is currently available through early access for teams seeking to test it with existing workflows and integrations.

Hosted AI agent environments differ substantially in their default outbound-network access, configuration models, enforcement gaps, and visibility, making it important to audit what each can reach before adding controls. Codex cloud blocks agent-phase internet access by default but permits unrestricted setup-script access with no documented restriction, while its local CLI requires both network access and a proxy setting for domain rules to work; ChatGPT Work offers a public-internet toggle but does not publish or let administrators modify its managed allowlist, and separate browser, search, and connected-app controls can bypass that setting. Claude Code’s local sandbox starts with no pre-approved domains and can enforce a strict allowlist, but critical settings must be applied through user or managed configuration rather than repository files, while its Bash-only boundary does not cover file tools, MCP servers, or hooks; Claude Code on the web publishes a broad default allowlist but retains documented bypasses for GitHub connectors, API-credential hosts, and Anthropic’s API. The discussion argues that network allowlists provide a stronger defense against prompt-injection-driven data exfiltration than detection systems because they can prevent destinations rather than merely identify suspicious behavior, although effective security also requires narrowly scoped credentials, default-deny tool permissions, and usable egress logging. A recent UK AI Security Institute incident, in which intentionally internet-enabled agents took unsanctioned real-world actions, is presented as an example of why internet access should be actively justified, regularly re-evaluated, and tested for inactive settings, missing proxy enforcement, and bypass paths.

As organizations scale AI agents, reliable authorization testing is needed to ensure agents can complete assigned work without exceeding user access, task-specific intent, or organizational policies. The guide proposes building repeatable test fixtures for workflows such as summarizing Linear issues and sending an email, recording the actor, authorized task, proposed action, policy version, expected authorization decision, and resulting external system state. It recommends beginning with allowed cases, then changing one variable at a time to test boundaries, including draft-versus-send permissions, role-based project access, restrictions on credentials or financial data, and protections against deleting received messages. Approval workflows should be tested end to end, including pending, approved, rejected, and modified requests, to confirm that approval applies only to the exact action reviewed. Crucially, a denial log alone is insufficient: tests must verify that prohibited actions did not occur in connected systems, while allowed decisions should be distinguished from delivery or provider failures. The approach also calls for testing dependency failures, retries, evaluator timeouts, and repeated model judgments, restoring account state between runs, and tracking both unsafe actions that executed and legitimate work that was blocked so policies can become safer and more useful over time.

Coding agents can reduce pull-request workload but require tightly scoped GitHub credentials to prevent review access from becoming unintended merge authority. For review tasks, GitHub App or fine-grained personal access tokens should provide only repository contents read access and pull-request write access, while merge-capable credentials, including other authenticated tools in the shell environment, should be isolated. Airlock, available in early access, can govern explicitly assigned merge actions by checking them against an agent’s task and organizational policies, requiring human approval where appropriate and applying conditions such as passing CI, approved reviews, limited change scope, and code-owner sign-off for sensitive areas. GitHub’s own branch protections, required checks, and review requirements should remain active without agent bypasses. To ensure approved code is the code merged, stale reviews should be dismissed after new commits, and merge requests should include the reviewed head commit SHA so GitHub rejects attempts to merge changed pull requests with a conflict, requiring the agent to review the updated revision again.

Airlock is presented as a framework for governing AI agents by combining a clearly defined task intent with an organization’s standing permissions and policies, ensuring that broader assignments do not grant authority beyond established rules. Task descriptions should specify the agent’s purpose, relevant timeframe, resources, and intended effects, such as identifying duplicate charges and issuing refunds, while leaving the agent flexibility to determine the operational steps needed. Identity, permissions, and policy must be managed independently of the task text, since an assignment cannot prove a requester’s authority or override restrictions such as limits on sharing financial data by email. Examples involving Linear, Gmail, billing searches, refunds, and blocked emails illustrate that decisions depend on the proposed action’s content, the stated objective, and applicable policy rather than simply on connected tools. Organizations are encouraged to test task clarity with realistic actions, record legitimate scope changes, and verify that rewording a denied request does not bypass enforcement.

WorkOS offers two iOS SDK clients for separate environments: PublicClient supports native mobile authentication using only a client ID, while WorkOSClient is intended for trusted Swift server processes such as Vapor applications, AWS Lambda functions, or shared API packages. WorkOSClient requires an API key that must remain server-side and provides typed asynchronous access to WorkOS resources including organizations, users, and directories, reducing the need to manually construct JSON requests or parse responses. The SDK supplies structured errors containing HTTP status, machine-readable codes, messages, request IDs, and field-level validation details, while automatically retrying transient failures such as timeouts, rate limits, and server errors without retrying genuine client errors. Its list endpoints use AsyncSequence to handle cursor-based pagination through `for try await` iteration, hiding the underlying page requests and cursor management. Together, the clients separate mobile sign-in from server-side resource management, enabling apps to authenticate users locally while securely handling WorkOS API operations on controlled backend infrastructure.

Agent Auth’s early-access chaining feature enables an agent to create child sessions for narrower, independently revocable portions of a long-running task while preserving the same agent identity and originating user context. Child sessions are minted server-side by an application backend, remain tied to the same blueprint and agent instance, cannot outlive the root session, cannot gain permissions beyond current blueprint and user authority, and cannot represent a different agent. Revocation cascades downward, allowing a risky batch such as billing writes to be stopped without ending unrelated work, while a user logout prevents further delegated session minting or refreshes. Chaining is intended to subdivide one agent’s authority over time rather than delegate work between different agents; multi-agent workflows should instead use separate blueprints and server-side sessions for each specialized agent. It is most useful around irreversible phases or batches, with descriptive but untrusted intent labels, job-appropriate maximum session ages, and external monitoring through webhooks, session listings, and application-recorded parent relationships.

WorkOS Airlock’s early-access approval workflow is designed to bind a human approver’s decision to one specific governed AI-agent tool call, such as a $1,200 customer refund, so that changes to the amount, charge, user, organization, or intent require a new review. Applications should create and persist an immutable refund request containing the transaction details, supporting billing evidence, authenticated user and tenant context, and a stable provider idempotency key, then present that exact request to an authorized reviewer. When approval is required, Airlock pauses the provider call and grants a one-time, request-matched pass; the application must resume the saved call after approval rather than treating the approval click as execution. It should preserve pending approvals across restarts, reject denied or expired decisions, prevent concurrent retries from consuming the same pass twice, and avoid assuming later policy edits revoke an existing approval. If a provider response is lost after an approved request may have succeeded, the application should mark the outcome unknown and query provider records instead of issuing another refund, while keeping authorization status distinct from proof of provider success. Testing should verify that altered requests cannot use prior approvals, invalid approvals cannot authorize calls, retries are safely constrained, and timeout recovery does not create duplicate refunds.

MCP OAuth scopes and valid access tokens can authorize an agent to invoke a tool such as sending email, but they do not determine whether the specific request content, recipient, or purpose complies with organizational policy. Effective enforcement therefore requires an MCP server or gateway to evaluate each complete tools/call request, including declared intent, trusted contextual records, and the exact arguments, before any provider action occurs. The request should be validated and frozen so that the recipient and content executed are identical to those evaluated, while denials, pending approvals, policy failures, and expired tokens prevent sending; approved actions should follow a separately validated approval path. Provider credentials should remain server-side rather than using the client’s MCP token, and testing should use recording stubs and test mailboxes to confirm that prohibited content, authorization failures, and policy timeouts result in no provider call. WorkOS Airlock is presented as an early-access authorization layer intended to apply such policy decisions to governed agent tool calls.

Enterprise security questionnaires often use identity-related questions to assess operational maturity rather than merely confirm feature availability, requiring vendors to explain SSO behavior, SCIM deprovisioning, termination-to-revocation timing, session invalidation, MFA enforcement, RBAC, self-service administration, and audit-log exports. Effective responses identify practical implementation details, such as support for IdP- and service-provider-initiated SAML flows, PATCH-based SCIM deactivation, identity-provider synchronization delays, token lifetimes, server-side session revocation, directory-group role mapping, and SIEM-compatible audit-log retention and delivery. The discussion emphasizes that vendors must independently address areas not solved by identity infrastructure, including subprocessors, data residency, incident response, secure development practices, and organizational compliance reports. It argues that reviewers can readily verify revocation processes, self-service setup, and real audit-log samples during follow-up calls, while presenting WorkOS products as tools for outsourcing much of the SSO, directory synchronization, MFA, RBAC, administrative configuration, and audit-log integration work.

WorkOS Vault provides local encryption that lets teams retain sensitive data within their own systems while outsourcing key management, tenant isolation, and key rotation infrastructure. It uses envelope encryption, generating a single-use data encryption key for each operation and protecting it with a longer-lived key encryption key stored in a non-exportable hardware security module. Applications use key contexts, such as organization identifiers, to automatically select or create isolated keys, with durable tenant-level contexts recommended to avoid key limits. In the underlying flow, Vault supplies a plaintext data key and its wrapped version, the application encrypts or decrypts data locally, and only wrapped key material is exchanged with WorkOS; SDK helpers simplify this process through high-level encrypt and decrypt methods. Vault also offers a separate storage API for customers who want WorkOS to persist encrypted objects, whereas local encryption is intended for organizations that control their own ciphertext storage. Its rekeying capability can move wrapped keys to a new context without decrypting or modifying the underlying data, supporting changes such as stronger tenant-specific isolation.

AuthKit integration in Rails can be set up through the WorkOS CLI, which installs the necessary gem, callback route, and dashboard redirect configuration, while preserving existing middleware. The authentication flow redirects users to a WorkOS-hosted sign-in page, exchanges the returned short-lived authorization code for an encrypted sealed session, and stores that opaque value in a secure, HTTP-only cookie rather than applying Rails encryption again. Correct Redirect URI, Initiate Login URL, and Sign-out URI settings are essential for authentication, invitation and password-reset flows, and logout behavior in production. On each request, Rails loads and authenticates the sealed session; expired sessions can be refreshed, with the newly sealed cookie requiring a redirect so the next request uses updated credentials. Refreshes should generally be limited to GET requests because redirects can discard POST data, and Turbo Frame behavior should be tested separately. Logout should use a CSRF-protected POST or DELETE request, revoke the live WorkOS session, clear the local cookie, and safely handle missing or invalid cookies. Applications needing local user records should create them once during the callback using the immutable WorkOS user ID rather than a mutable email address, while WorkOS manages token cryptography, rotation, and future enterprise SSO support.

AuthKit and Better Auth have both evolved into platforms offering enterprise authentication features such as SAML SSO, SCIM provisioning, organizations, RBAC, MFA, passkeys, dashboards, audit logs, and SIEM integrations, making a simple library-versus-hosted-service comparison outdated. The discussion argues that their main distinction lies in enterprise operational depth rather than feature checklists: WorkOS emphasizes more than 60 maintained identity-provider, directory, and HRIS integrations, including direct connections to Workday, BambooHR, and Rippling for lifecycle events, while Better Auth provides provider-agnostic SSO and SCIM but has not published comparable provider-specific or HRIS coverage. WorkOS also cites a public 99.99% SLA for key services, whereas Better Auth’s newer hosted offering should be evaluated against its current contractual terms. Better Auth may suit teams prioritizing open-source control, repository-based authentication, or newer areas such as agent identity, while AuthKit is positioned for B2B software companies facing enterprise security reviews, complex identity-provider requirements, employee offboarding expectations, and contractual uptime demands. AuthKit is free up to one million monthly active users and charges per enterprise SSO or directory connection, but neither hosted option fits air-gapped environments that require authentication services to remain entirely within a customer’s network.

Impersonation sessions are easy to enable through identity providers but can create broad downstream risks because applications and integrations typically treat the support engineer’s activity as if it were the customer’s. Potential consequences include misleading transactional, lifecycle, and chat notifications; inaccurate webhooks, analytics, session recordings, login timestamps, error reports, rate limits, feature-flag assignments, caches, and background jobs that lose actor context after the session ends. A recommended approach is to derive a single support-session flag from authenticated impersonator data at session creation, make it available before third-party tools initialize, and have every relevant integration consult it, while ensuring failures preserve normal behavior rather than disabling services globally. Rather than allowing operators to suppress notifications manually, applications should suppress misleading user-action alerts while providing a deliberate, independent access notification and customer-visible audit record. Effective audit trails should retain both the acting support employee and the customer identity, record the reason, and capture both session start and end. Identity providers such as WorkOS can supply impersonator metadata and session expiration, but application teams remain responsible for handling their own emails, analytics, webhooks, queues, billing, and other side effects through a deliberate pre-release review.

Sierra’s experience building an internal Model Context Protocol gateway shows that connecting agents to 45 services for most employees was less constrained by integrations than by the underlying identity, authorization, consent, and auditing systems needed for safe deployment. Its approach included per-tool permissions, organization-scoped access, detailed audit records, session-limited human approvals for exceptions, customer-data classification for unstructured sources, and separate least-privilege identities for interactive users, scheduled workflows, and agents. The discussion argues that MCP specifications have historically left important gateway behaviors, including authorization propagation and client identity, insufficiently defined, causing companies to develop similar private solutions. It also notes that gateways cannot cover every workflow, since agents may use established command-line tools or custom extensions that introduce additional credential surfaces and require controls beyond a proxy. Recent MCP standards favor Client ID Metadata Documents over Dynamic Client Registration, while the broader conclusion is that organizations should build specialized controls unique to their data but consider using established identity, OAuth, permission, and audit infrastructure for common authorization requirements.

Neon’s Claimable Neon implementation uses the auth.md protocol to let agents provision a temporary, restricted Postgres project when no human account or API key is available, allowing development to continue until a person can take ownership. Agents discover the appropriate registration flow through Neon’s published metadata, use anonymous registration to request supported capabilities such as Postgres, the Data API, and Managed Better Auth, and must inspect which services were actually granted. Unclaimed projects are limited to 72 hours, 100 MB of storage, and 1 GB of transfer, while some services require a completed claim. Neon separates a durable registration assertion from short-lived access tokens, reducing reliance on a person’s existing credentials but requiring agents to protect the assertion until the project is claimed, expires, or is revoked. A human can claim a project through a short-lived URL, after which Neon transfers it to an organization, revokes temporary access, rotates database credentials, and ultimately invalidates the agent’s assertion. The approach demonstrates how auth.md can provide agents with discoverable, bounded access to stateful infrastructure while preserving service-defined controls, quotas, and explicit human ownership transfer.

WorkOS has expanded Generic OIDC connection settings to address real-world differences among identity providers despite their shared adherence to OpenID Connect standards. Administrators can now select per-connection token-endpoint authentication methods, including client secret basic, client secret POST, and private key JWT, with the latter generating a signing key pair and requiring providers to register the public key. ID token signature algorithms can also be configured across RSA, RSA-PSS, ECDSA, EdDSA, and HMAC options, while preventing incompatible combinations such as HMAC signatures with private key JWT. A UserInfo endpoint option lets connections retrieve profile claims such as email and names when they are absent from ID tokens, while verifying that the returned subject matches the token’s subject. PKCE remains enabled by default in response to modern OAuth requirements and provider enforcement, though it can be disabled for exceptional compatibility issues. Finally, client IDs and secrets can now be updated directly on active connections, avoiding setup resets and login interruptions when credentials expire or rotate.

Reliable employee deprovisioning is a security and audit-critical challenge because terminations often arrive as soft deactivations rather than deletes, identity providers implement SCIM PATCH operations differently, and authoritative HR or directory systems may rely on APIs, polling, or scheduled file transfers instead of SCIM. WorkOS Directory Sync presents these varied inputs through normalized directory, user, and group events, with user deletion events retaining whether the person was inactive or merely unassigned, while stable external IDs rather than mutable emails should be used for reconciliation and reactivation. Effective implementations must revoke active sessions, OAuth tokens, API keys, cached permissions, and account access rather than simply change a database flag, while accounting for latency from identity-provider sync cycles and JWT expiration. The recommended approach treats event streams as a latency optimization backed by scheduled full reconciliation, makes all update paths idempotent, defines source-of-truth priorities for conflicting systems, and retains inactive user records with timestamps and reasons. Detailed append-only audit logs and SCIM request logs provide evidence of what was received and revoked, helping organizations investigate missed events and satisfy access-removal audits, while managed directory-sync services reduce the burden of maintaining provider-specific connectors, normalization, polling, and debugging.

OpenID Connect Back-Channel Logout, finalized in 2022 and updated with errata in December 2023, enables identity providers to notify applications server-to-server when a user session should end, such as after central logout or account deactivation. Providers advertise support, applications register a reachable logout endpoint, and the provider POSTs a signed logout JWT containing required claims and either a session identifier, user identifier, or both. Applications must rigorously validate the token’s signature, issuer, audience, expiration, logout event, prohibited nonce, and replay identifier, then respond idempotently while preventing cached responses. The principal implementation challenge is not the endpoint itself but maintaining a server-side mapping between the provider’s session ID and local sessions, allowing the application to revoke session records, relevant refresh tokens, and possibly manage still-valid access tokens without relying on browser cookies. Adoption remains limited because endpoints must accept inbound requests from every supported provider and because many applications lack session infrastructure capable of immediate invalidation. Back-channel logout addresses central logout and account disablement but not broader mid-session signals such as role changes or device posture, which Continuous Access Evaluation Protocol can provide where available; consequently, shorter session lifetimes, storing session IDs at login, and implementing invalidatable server-side sessions are presented as practical preparatory steps.

Enterprise-Managed Authorization (EMA) for the Model Context Protocol became Stable in June 2026, allowing company administrators to authorize MCP client-to-server access centrally through a shared identity provider rather than requiring each employee to complete interactive consent flows. The system uses the emerging ID-JAG standard, a short-lived signed JWT issued through OAuth token exchange that asserts a specific user, client, authorization server audience, resource server, and permitted scopes; the receiving authorization server must validate it and exchange it for a normal access token rather than treating it as a bearer token. EMA depends on both the client and resource authorization server independently trusting the same enterprise IdP, with the IdP enforcing organizational policies such as group-based permissions, conditional access, and scope restrictions. Critical implementation concerns include strict validation of typed JWT headers, audience and client bindings, issuer signatures, expiry, subject resolution, and multi-tenant identity claims, while avoiding token-substitution and account-linking vulnerabilities. Although ID-JAGs may be reused to obtain fresh access tokens within their intended authorization-server audience, implementations should not issue refresh tokens for them or permit use across different downstream authorization servers. Deployments also require operational work around client-ID mapping, confidential-client support, fallback interactive authorization, IdP trust configuration, and privacy-preserving discovery metadata. EMA centralizes the initial access decision but does not provide visibility into subsequent MCP tool calls or data transfers, leaving server operators responsible for audit logging, account linking, and federation management.

WorkOS AuthKit simplifies enterprise SSO implementation by handling SAML, OIDC, routing, and identity-provider integrations without requiring SSO-specific application code, leaving developers to focus on tenant organization design, connection administration, user migration effects, and testing. Applications should create and persist WorkOS organization IDs during customer onboarding, use those IDs rather than email domains to authorize tenant access, and account for the limitation of one identity-provider connection per organization, potentially mapping one commercial customer to multiple organizations. Customers can configure their own connections through short-lived, protected Admin Portal links, reducing support work, but enabling SSO automatically disables other authentication methods for that organization, making advance communication essential for existing password users. Just-in-time provisioning supports users on verified domains, while guests and contractors may require invitations or separate authentication policies. Reliable deployment requires testing service-provider- and identity-provider-initiated sign-in, guest-domain behavior, and error cases, as well as separating staging from production configuration. The account should also plan for directory sync through SCIM, since SSO controls sign-in but does not automatically remove departed employees’ memberships or access.

Audit logging is only reliable when event creation is coupled to the business action it records, since separate writes can create missing events, false records, or duplicates during failures and retries. For events stored locally, placing both the action and audit record in a single database transaction ensures that both succeed or fail together; when events must reach an external system, a transactional outbox records the event locally in that same transaction and a worker later delivers it reliably. Undelivered outbox records should remain available for retries and be monitored by the age of the oldest pending event rather than queue depth alone. Delivery must use stable idempotency keys so retries do not create duplicate audit entries. Teams should also explicitly decide which audit failures must block user actions, alert on failed writes, regularly reconcile expected business actions against delivered events, and test sink outages to verify recovery. While managed audit backends can provide durable storage, searchability, retention, and downstream integrations, the application’s own transaction, outbox worker, and reconciliation processes determine whether the audit trail is complete.

An evaluation of ChatGPT Codex credit top-ups found that 1,000 credits for $40 translate directly to OpenAI’s standard API token prices, making them prepaid API-priced usage rather than a discount. In blinded tests of a long TypeScript agent task, the Codex subscription endpoint and standard API endpoint produced statistically indistinguishable quality results, but Codex was about 1.5 times slower despite similar reasoning and output token use, with more in-run API errors. Codex Fast mode restored performance to roughly standard API speed but consumed credits at a 2.5-times multiplier, while the API priority tier was faster still at a lower derived cost than Codex Fast. Credits may retain value for included subscription allowance, unbilled cache writes, and access to Codex cloud integrations such as GitHub review and Slack, but purchased credits also expire after 12 months and have restrictive terms. Based on measurements limited to one model, workload, account, region, and five days in August 2026, the authors recommend using included Codex allowance first and shifting overflow work to the API, testing endpoint performance on an organization’s own tasks before buying additional credits.

Okta, Auth0, and Descope released closely timed support for Cross App Access and the ID-JAG protocol, signaling growing agreement on an enterprise agent-access model built around two layers: Client ID Metadata Documents (CIMD) for portable client identification and ID-JAG token exchanges for identity-provider-controlled delegation. The approach allows enterprise administrators to govern which AI agents and requesting applications can access APIs, applications, and MCP servers, while resource authorization servers retain control over token issuance, scopes, and local policy. Okta’s Agent SSO emphasizes distribution through its integration network, Auth0 supports both requesting and resource application roles, and Descope targets B2B software teams with self-service configuration for trusted issuers and agents. Although Okta helped lead the protocol and currently has a prominent connector ecosystem, support from other vendors, standards-compliant identity providers, and MCP SDKs suggests the pattern may operate across vendors rather than remain proprietary. The text argues that B2B teams should prioritize whether their authorization servers support enterprise-managed authorization, including JWT bearer grants, external client metadata, and per-tenant trusted-issuer policies, because enterprise customers increasingly seek alternatives to per-user consent and long-lived shared API keys for agent access.

MCP authorization uses OAuth 2.1 to let AI agents access protected HTTP-based MCP servers on a user’s behalf with short-lived, server-specific access tokens rather than passwords or persistent API keys, while STDIO servers should instead obtain credentials from their environment. Under the current 2026-07-28 specification, the MCP server acts as an OAuth resource server that discovers and trusts a separate authorization server, validates tokens, enforces exact audience binding through the RFC 8707 resource parameter, and never forwards received tokens upstream. Clients discover Protected Resource Metadata and authorization-server metadata, use mandatory PKCE, validate callback issuers to prevent mix-up attacks, and generally register through Client ID Metadata Documents, with Dynamic Client Registration now deprecated. Servers must return 401 for missing or invalid tokens and 403 for insufficient permissions, allowing clients to perform step-up authorization by requesting the union of existing and newly required scopes. Although the specification defines token acquisition and validation requirements, it leaves application-specific decisions—such as which identities may use particular tools or resources, authorization-server operation, and unattended-agent delegation—to implementers.

Agent Auth, a WorkOS early-access feature for first-party agents, addresses the limitation of user-scoped API keys by allowing agents to operate with permissions limited independently from the initiating user. It uses reusable blueprints that define an agent’s permission ceiling, eligible invokers, and token and session lifetimes; delegated agents receive only the intersection of the user’s permissions and the blueprint’s ceiling, while autonomous agents receive the ceiling alone. Tokens identify both the agent as the actor and, for delegated sessions, the user whose authority it uses, improving auditability without granting excessive access. Permissions are recalculated whenever tokens refresh, so role changes, sign-outs, removals, and revocations quickly reduce or end agent access. The approach encourages narrowly task-focused permissions, restricted invocation rules, short-lived tokens, and monitoring through agent lifecycle events. It does not govern third-party agents or resource-level access such as particular projects or records, so applications must continue enforcing fine-grained authorization at tool boundaries.

Agent permission systems often focus on syntactically recognizable shell risks while failing to assess the potentially irreversible business impact of API actions such as closing CRM opportunities, sending emails, issuing refunds, or deleting production data. The passage argues that frequent prompts create approval fatigue, citing Anthropic’s finding that users approve 93% of requests, while blanket permission bypasses remove meaningful oversight; Claude Code’s auto mode reduces interruptions through input probing and per-action classification but still misses some risky actions because it cannot fully determine whether an action matches a user’s intended scope. It distinguishes failures caused by agent overeagerness, overly broad OAuth token permissions, and tools whose behavior changes after approval, arguing that each requires different controls and that one-time authorization is insufficient for mutable integrations. A more effective organizational model would evaluate every outbound API request in relation to an explicitly declared task, enforce non-negotiable static limits such as prohibiting direct production changes or high-value refunds, use human escalation selectively, and maintain action-level audit records. The passage presents WorkOS Airlock, currently in early access, as a gateway designed to apply such task-aware static and runtime policies across agent integrations, while withholding provider credentials from agents and routing escalations through Slack.

AuthKit provides a production-ready authentication system for Next.js App Router applications, covering sign-up, sign-in, password recovery, email verification, multifactor authentication, social login, and session management through WorkOS. The integration can be completed quickly with the WorkOS CLI installer, which detects the framework, configures dashboard settings and environment variables, adds required routes and providers, and validates the build, or manually by installing the SDK and configuring redirect, sign-out, and initiate-login URLs. Manual setup involves encrypting session cookies with a sufficiently long password, wrapping the application in `AuthKitProvider`, adding either a dedicated or composable proxy to manage sessions and route access, and creating callback and login endpoints. Developers can retrieve authenticated users in server or client components, protect pages using `ensureSignedIn`, and sign users out through a server action. The tutorial also recommends testing the complete sign-up and sign-in flow locally and identifies common configuration problems involving sign-out URLs, cookie handling, and exact callback URI matches, with `workos doctor` available for further diagnostics.

Production cloud compromise paths often begin with CI/CD workload identities rather than user accounts, because service principals, managed identities, and federated deployment roles frequently escape normal access reviews and lack clear ownership or lifecycle controls. Although short-lived GitHub Actions OIDC tokens reduce reliance on static secrets, their security depends on precisely scoped trust-policy claims; broad repository wildcards can let any eligible branch, pull request, or environment assume a privileged role, while protected environments, reusable-workflow references, and evolving immutable GitHub subject formats require careful configuration. The text emphasizes that the greater escalation risk is often ownership: anyone able to add credentials, alter federation, grant consent, or modify permissions on a privileged application can create durable access without compromising the original CI runner. Detection tools provide useful visibility into suspicious token use but are less comprehensive for credential and configuration grants, especially for managed identities and other identities outside Conditional Access coverage, making audit alerts for credential additions, federation changes, role grants, and subsequent resource access important. Recommended defenses include inventorying who controls every workload identity, replacing long-lived secrets with tightly restricted federation, separating build and deployment identities, removing unnecessary standing roles, enforcing production approvals, rotating compromised credentials and reachable secrets, and maintaining an attack-path graph that maps identities, ownership, permissions, trust relationships, and accessible resources.

AI agents intensify identity and audit challenges because they can act continuously and rapidly under delegated human authority, making it essential to link credentials with records of application-level actions. FusionAuth 1.69 introduces a dedicated AI Agent entity, lifecycle webhooks, audit and event logging, stronger issuer and key-validation controls, and existing DPoP support, providing self-hosted teams with robust identity-provider events and delivery infrastructure; however, application resource actions such as document access must still be logged, retained, and correlated separately. WorkOS’s AuthKit Agent Registration uses the auth.md protocol and OAuth metadata discovery to let agents self-register for scoped, short-lived credentials, initially anonymously or through trusted service authentication, with a claim process that binds an agent to a user. Its tokens include the agent registration ID, organization, scopes, and an RFC 8693-style delegation claim identifying the authorizing user, enabling application audit events to use the same identifiers. WorkOS Audit Logs and Log Streams provide managed storage and delivery to common security and analytics destinations, although customers must define event schemas and decide which actions to record. The central distinction is whether organizations prefer FusionAuth’s self-operated identity infrastructure and separately joined application audit records or WorkOS’s hosted system that combines agent registration, delegated credentials, and application audit trails around a shared identifier.

MCP’s existing Step-Up Authorization Flow handles insufficient OAuth scopes, allowing servers to return a 403 insufficient_scope challenge and clients to request broader permissions, but it does not address whether a human user has recently re-authenticated or remains present for a sensitive action. That distinct authentication step-up problem is covered by RFC 9470 through concepts such as insufficient_user_authentication, acr_values, max_age, and auth_time, none of which MCP currently adopts. This gap is especially significant for long-running, unattended, and resumable agent sessions, where a valid token with durable permissions may be tied to an authentication event from hours or days earlier. MCP’s URL mode elicitation can support an out-of-band browser-based approval process and requires servers to verify the identity of the user completing it, but it does not provide a standard way to require authentication freshness. Until MCP and authorization servers support RFC 9470-style challenges, servers handling destructive operations should implement their own short-lived, single-use approvals bound to the verified user identity, the exact operation and its arguments, and a fresh authentication event.