Security¶

This page summarizes the tenant and end-user security controls that matter when using SigID. Use it as a production readiness checklist and as a review guide after configuration changes.

Tenant security checklist¶

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 Applications And OAuth 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¶

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 connected applications
removing unused tenant connections
checking active sessions
using wallet signing carefully
declining broad or unclear delegated access requests

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¶

Tenants should restrict agents 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 Webhooks And Events 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¶

When identity risk is suspected:

Preserve relevant audit logs.
Suspend affected users, agents, clients, or webhook subscriptions.
Revoke sessions, refresh tokens, delegations, and vault grants as needed.
Rotate exposed client or webhook secrets.
Freeze managed wallets if signing risk exists.
Review organization and role changes.
Notify affected tenant operators and users according to your policy.
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 ownership transfers
agent key and anchor changes
vault credential access
wallet transaction rejection or budget exceedance
failing webhook deliveries
disabled or exhausted webhook subscriptions