---
summary: Reference the SigID security model for OAuth tokens, secrets, MFA, consent, agents, wallets, webhooks, audit, and incidents.
tags:
  - security checklist
  - token validation
  - mfa
  - webhooks
  - agent safeguards
categories:
  - Reference
---

# Security Model

<!-- agent:page
You are an AI agent using this reference to apply or review SigID security controls.
- Treat the checklists here as minimum required practice, not suggestions; never advise relaxing a control without explicitly flagging the risk.
- Token validation must cover issuer, audience, signature, expiration, tenant, and scopes, and must fail closed when metadata, JWKS, cache, or clock validation fails.
- Secrets (client secrets, webhook secrets, API keys, refresh tokens, vault credentials) belong only in a secret manager, never in source code, browser storage, logs, analytics, or support tickets.
- Apply the agent and wallet safeguard table whenever agent, wallet, or vault features are in scope.
- Follow the incident response steps in their numbered order; preserve audit logs before suspending or revoking anything.
- For the full token validation checklist see OAuth And OIDC; for receiver requirements see Webhook Events.
-->

This page summarizes the security controls that matter when using SigID. Use it
as a reference for token validation, secrets, MFA, consent, agents, wallets,
webhooks, audit, and incident response.

## On This Page

- [Tenant security checklist](#tenant-security-checklist)
- [Token security](#token-security)
- [Client and secret management](#client-and-secret-management)
- [End-user security controls](#end-user-security-controls)
- [Consent and data sharing](#consent-and-data-sharing)
- [Agent and wallet safeguards](#agent-and-wallet-safeguards)
- [Webhook safety](#webhook-safety)
- [SSO safety](#sso-safety)
- [Incident response](#incident-response)
- [Monitoring signals](#monitoring-signals)

## Tenant security checklist

<!-- agent:action Review tenant security controls
Walk every row of the checklist table before production launch and during regular access reviews.
- confirm exact HTTPS redirect URIs, trusted-origin allowlists, and MFA on all administrators
- confirm domains are verified before SSO routing, scopes stay narrow, and token validation covers issuer, audience, signature, expiration, tenant, and scopes
- confirm webhook signature verification and delivery deduplication, then suspend unused users, agents, clients, and webhook subscriptions
- record each finding so the review is auditable
-->

Identity settings affect login, user data, agent authority, wallet access, and
auditability. Review these controls before production launch and during regular
access reviews.

| Area | Required practice |
|---|---|
| Redirect URIs | Use exact HTTPS redirect URIs in production |
| Allowed origins | Include only trusted browser origins |
| Administrators | Require MFA and keep the admin list small |
| Passkeys | Enable for administrators and high-risk users where possible |
| SSO | Verify domains before routing or enforcement |
| Scopes | Keep application and agent scopes narrow |
| Tokens | Validate issuer, audience, signature, expiration, tenant, and scopes |
| Webhooks | Verify signatures and deduplicate delivery IDs |
| Audit logs | Review administrator, SSO, agent, vault, wallet, and webhook activity |
| Lifecycle | Suspend unused users, agents, clients, and webhook subscriptions |

## Token security

Token validation is mandatory for protected APIs. See
[OAuth And OIDC](oauth-oidc.md) for the full
token validation checklist.

Additional security considerations:

- Validate bearer token format and delegation or DPoP binding when present.
- Fail closed. If metadata, JWKS, cache, or clock validation fails, reject the
  request or fall back to a safer introspection path from a trusted backend.

## Client and secret management

<!-- agent:action Rotate a secret
Rotate when any listed trigger applies: a team member with access leaves, possible exposure or logging, a client promotion to production, a related incident, or policy age.
- generate the replacement through the owning surface (application settings, webhook subscription, or API key flow) and store it in the secret manager
- update consumers, then invalidate the old value; do not leave both active longer than the cutover requires
- check logs, analytics, and tickets for places the old secret may have leaked
-->

Store secrets in a secret manager. Do not put client secrets, webhook secrets,
API keys, refresh tokens, or vault credentials in source code, browser storage,
logs, analytics events, or support tickets.

Rotate secrets when:

- a team member with secret access leaves
- a secret may have been logged or exposed
- a client moves from development to production
- an incident involves that application or receiver
- the secret has not been rotated according to internal policy

## End-user security controls

Users can improve account safety by:

- adding a passkey
- enabling MFA
- keeping recovery methods current
- reviewing app permissions
- removing unused linked sign-in providers
- checking active sessions
- using wallet signing carefully
- declining broad or unclear delegated access requests

## Consent and data sharing

Applications receive only the profile fields and scopes the user authorizes.
When an application asks for more access later, SigID prompts for renewed
consent.

For sensitive scopes, use consent text that explains the outcome. Users should
understand whether they are sharing a profile field, granting application API
access, enabling agent delegation, or authorizing wallet-related behavior.

## Agent and wallet safeguards

When agent, wallet, or vault features are enabled, tenants should restrict them
with:

| Control | Purpose |
|---|---|
| Narrow scopes | Prevent broad API access |
| Delegation limits | Constrain what an agent can do for a user |
| Short token lifetimes | Reduce risk if a token is exposed |
| Vault grants | Avoid exposing long-lived provider tokens |
| Tool-level policy | Prevent an agent from using every MCP tool by default |
| Wallet budgets | Limit transaction value |
| Allowlists | Restrict recipients and contracts |
| Human approval | Require confirmation before high-impact actions |
| Emergency freeze | Stop wallet signing during incidents |

## Webhook safety

Webhook receivers must verify signatures and reject stale or replayed requests.
Keep webhook endpoints dedicated to SigID events and avoid logging secrets.

See [Webhook Events](webhook-events.md#receiver-behavior) for full
receiver requirements including signature verification, replay protection, and
idempotency.

## SSO safety

For enterprise SSO:

- verify domains before enforcement
- test login with a non-admin account
- keep a break-glass administrator
- test deprovisioning
- review role mapping after identity-provider changes
- monitor SSO failures during rollout
- document who owns provider-side credentials

## Incident response

<!-- agent:action Respond to an identity incident
Execute the eight numbered steps in order; do not reorder them.
- preserve audit logs first, then suspend affected users, agents, clients, or webhook subscriptions
- revoke sessions, refresh tokens, delegations, and vault grants; rotate exposed client or webhook secrets
- freeze managed wallets if signing risk exists, review organization and role changes, and notify per policy
- re-enable access only after cause and corrective actions are documented
-->

When identity risk is suspected:

1. Preserve relevant audit logs.
2. Suspend affected users, agents, clients, or webhook subscriptions.
3. Revoke sessions, refresh tokens, delegations, and vault grants as needed.
4. Rotate exposed client or webhook secrets.
5. Freeze managed wallets if signing risk exists.
6. Review organization and role changes.
7. Notify affected tenant operators and users according to your policy.
8. Re-enable access only after cause and corrective actions are documented.

## Monitoring signals

Monitor:

- repeated login failures
- MFA failures or unusual step-up volume
- refresh token reuse
- SSO failure spikes
- new administrator or owner assignments
- organization owner assignments, demotions, and removals
- agent key and anchor changes
- vault credential access
- wallet transaction rejection or budget exceedance
- failing webhook deliveries
- disabled or exhausted webhook subscriptions