Agents, MCP, and Machine-to-Machine Access

Guardhouse does not require a separate identity protocol or management API for AI agents. An agent, MCP server, worker, daemon, or backend service is a non-human OAuth client. Register it as a confidential service client and use the client credentials flow.

Model the Integration

Create these objects in Guardhouse:

1. An API resource for the service the machine will call.
2. Narrow scopes for the operations that API exposes.
3. A separate service client for each workload and environment.
4. A client secret stored only in the workload's secret store.

Do not share one client across unrelated agents or environments. Separate clients make rotation, revocation, attribution, and least-privilege reviews practical.

Request a Token

Request only the scope needed for the current API. Use the tenant's /connect/token endpoint with grant_type=client_credentials, the service client ID and secret, and an allowed API scope.

Cache the access token until it approaches expiration. Do not request a new token for every tool call, and never place the secret or access token in a prompt, trace, model context, browser bundle, or source repository.

For a complete request example and language-specific token clients, see the machine-to-machine quickstart and SDK overview.

Protect an MCP Server or Tool API

Treat the MCP server or HTTP tool service as the API resource:

• require bearer authentication at the network boundary;
• validate the canonical Guardhouse issuer and the server's audience;
• validate token lifetime and signature, or use introspection;
• require an operation-specific scope before invoking a tool;
• apply application authorization after token validation;
• avoid returning credentials or sensitive tool output in errors.

OAuth authenticates the calling workload. It does not make model-generated arguments safe. Validate tool inputs, constrain downstream credentials, and require human approval for consequential operations where appropriate.

JWT Validation or Introspection

Local JWT validation avoids a network request on each call and keeps the API available when the authorization server is temporarily unreachable. Introspection asks Guardhouse whether a token is currently active and uses confidential resource credentials.

Choose the trade-off for the protected API, not for the model. See Protect an API.

Credential Lifecycle

• Store secrets in a managed secret store and limit who and what can read them.
• Rotate secrets on a schedule and immediately after suspected exposure.
• Revoke or disable clients that are no longer used.
• Keep development, staging, and production identities separate.
• Log the client identity and authorization decision, but never the token or secret.
• Rate-limit and monitor the protected API based on its risk and capacity.

System API Access

The built-in system_api scope is only for trusted administrative automation of users, roles, and permissions. It is not an agent-management scope and should not be granted to an ordinary agent or MCP client.

Guardhouse does not expose a dedicated agent- or MCP-management API. Build integrations with the standard OAuth and protected-resource patterns documented here.