Runtime Authorization

Purpose

This functional area decides whether a caller is allowed to invoke a tool.

Main Capabilities

• default-deny enforcement

• policy evaluation per tool

• tenant-aware authorization

• claim-based access matching

• browser-based operator approval for runtime OAuth authorization requests

• alignment between runtime browser authorization and the operator's current Portal session context

• immediate rejection of tokens whose underlying session has been revoked

• enforcement of the scope a user actually consented to, above and independent of per-tool policy

• an immediate platform-side kill switch that no tool owner can override

Supported Policy Dimensions

• issuer
• client ID
• roles
• scopes
• groups
• custom claim requirements

Consented Scope Enforcement

When an AI client obtains access through the OAuth authorization flow, the user is shown what the client is asking for and approves it. That approval is a ceiling, enforced by the Runtime on every call.

Four scopes exist, deliberately few enough that a person can reason about them at a consent screen:

Functionally this means:

• discovery requires tools:read and invocation requires tools:invoke, checked before any per-tool access policy is evaluated — so a client that was never consented for invocation cannot call anything, whatever the tools' own policies say
• tools:invoke does not imply tools:read; a client that needs both asks for both
• the scopes granted are the intersection of what the user approved and what the client registered, never the union
• what the user approved is recorded at the moment of approval, so re-registering the client later cannot silently widen an approval already given
• a scope can never authorise anything the consenting user could not do themselves: the token still carries only that user's own authority, and the tool's access policy still applies on top

This closes a gap in which a delegated client token carried the consenting user's full authority on the Runtime, MCP and A2A surfaces, with no configuration an operator could write that narrowed it.

Platform Quarantine

Independently of any access policy, a tool can be taken offline from the Portal's Tool Oversight screen by an operator holding the Security area's authority.

Functionally this means:

• the Runtime refuses every call to a quarantined tool immediately, whatever that tool's own access policies permit
• the tool's owner cannot lift it by re-enabling their own policies — only the Security area can release it
• the reason recorded when the tool was taken offline is shown to its owner and written to the audit trail, so the refusal says what has to be fixed

This is the control for the case where a tool has to stop serving now and the person who can see the problem is not the person who publishes the tool.

Browser Authorization Flow

For browser-capable runtime clients, authorization is mediated through the Portal login experience.

Functionally this means:

• the runtime authorization request is redirected into Portal.Web with the original OAuth parameters preserved
• operators can complete the same sign-in requirements they would for any normal portal session, including external provider authentication and MFA
• after authentication, the Portal presents a dedicated authorization review step instead of silently completing the request
• the operator must explicitly confirm that the requesting application should receive runtime access through the current portal account
• the resulting authorization code inherits the same tenant scope and effective permissions as the authenticated portal session that approved it

This keeps runtime browser authorization consistent with the platform's human sign-in and consent controls instead of maintaining a separate reduced-capability login surface.

Session Revocation Enforcement

Access tokens presented to the Runtime are checked against session revocation state on every request, not just at issuance time.

Functionally this means:

• when an operator or administrator revokes a session in the Portal, any access token already issued from that session stops working the next time it is presented to the Runtime — the caller does not need to wait for the token's own expiry
• this applies uniformly regardless of how the token was obtained: local sign-in, external identity provider sign-in, the device authorization flow, or the runtime OAuth authorization-code flow
• if the platform detects signs of refresh-token theft (a stale or already-used token being replayed) and automatically revokes every active session for that account as a precaution, all of those sessions' tokens are rejected by the Runtime immediately, not just the one that triggered the detection
• revocation is enforced consistently whether the token is presented to the Runtime or back to the Portal itself

This closes a gap where a session that had been explicitly revoked, or automatically revoked in response to suspected token theft, could still be used to invoke tools against the Runtime until its access token expired on its own.

Functional Value

This area ensures the Runtime is not just discoverable, but governed at the point of use.