A credential lease is a short-lived server-side grant that allows one organization to use one approved model through one provider gateway. Members select a model; their browsers never receive the provider credential.
Lease model
The lease records issuer, subject, organization, Environment, provider/gateway, model, scope, issue and expiry time, and decision evidence. It is authority for a trusted service, not a secret that may be returned to the member.
Checks before a lease is issued
- The person belongs to the active organization.
- The gateway is available to that organization.
- The requested model belongs to the gateway and is approved.
- A managed gateway still has a ready deployment.
- The provider registry entry and required capability qualification are current.
- Budget and allocation authority can cover the request.
- The lease is scoped to that organization, gateway, and model and expires quickly.
Lease caches include organization identity. Two organizations requesting the same model do not share a credential grant.
Use and revoke a lease
Only the trusted runner or worker redeems the lease. Revalidate expiry and scope at use, and revoke the lease when access, model availability, or incident posture changes.
Bind leases to external actions
A model lease permits model access; it does not approve a tool's external effect. Preserve the separate, exact action approval and validate both authorities before execution.
Investigate a denied model request
Confirm the organization, gateway visibility, model approval, deployment readiness, and lease issuance in that order. Do not work around a denial by sending a raw provider credential to the browser or silently selecting another model.
Record the first failed decision—membership, Environment, registry, qualification, capability, budget, readiness, lease, or provider response—so an operator fixes the owning boundary.