AI Agents

SigID lets tenants treat AI agents as first-class principals. Agents can sign in directly, call APIs with their own authority, and act for users through reduced delegated tokens.

Agent identity

An agent should have a stable identity independent of the machine where it is running. SigID supports multiple identity anchors so tenants can choose the level of portability and assurance they need.

Anchor	Use when	Operational note
ERC-8004	You need portable on-chain agent identity	Useful when reputation or ownership moves across platforms
did:web	You control a domain and want web-based identity proof	Aligns agent identity with an owned domain
did:key	You need a simple key-based identity	Easy to bootstrap but harder to rotate operationally
Client credentials	You are integrating an existing service client	Familiar for backend services but less portable

Agents can have multiple anchors. Tenant policy decides which anchors are trusted for each use case.

Agent registration flow

1. Create the agent record.
2. Add one or more identity anchors.
3. Complete challenge-response verification.
4. Register public keys needed by the runtime.
5. Assign scopes and policy constraints.
6. Test token issuance as the agent.
7. Subscribe to agent audit events or webhooks.

Definition of done:

• The agent has at least one verified anchor.
• The agent can prove key possession.
• The tenant can revoke anchors and keys independently.
• Audit logs show registration, verification, key changes, and access events.

Agent access patterns

Pattern	Description	Required controls
Agent acts as itself	The agent receives a tenant-scoped token for its own subject	Agent scopes and audience checks
Agent acts for a user	SigID issues a reduced delegated token after user consent and policy checks	Consent, delegation limits, time bounds
Agent calls a third-party tool	SigID grants scoped access through the credential vault	Vault grant, expiry, revocation
Agent uses an MCP server	The MCP server validates OAuth tokens and required scopes	Audience, scopes, subject type, delegation claims
Agent signs with a managed wallet	SigID enforces wallet policy before signing	Budget, allowlist, approval, freeze

Delegated user access

Delegation should always reduce authority. When an agent acts for a user, SigID narrows access by combining:

• user consent
• requested scopes
• tenant policy
• agent delegation limits
• time bounds
• subject type
• risk or step-up requirements

The agent should never receive broad user access just because the user is signed in.

Recommended delegated token design:

Claim or property	Recommendation
Audience	The exact API or tool the agent will call
Scope	Narrow capability, not a broad user role
Subject	Agent or delegated subject context must be explicit
Expiry	Short-lived for sensitive workflows
Delegation ID	Traceable to consent and policy decision
DPoP binding	Use when the caller can prove key possession

Credential vault

Use the vault when an agent needs to call an external provider such as email, calendar, source control, storage, or support tooling. The tenant or user can revoke vault grants without rotating application credentials.

Vault guidance:

• request provider access at the point of need
• keep grants scoped to a provider, resource, and purpose
• prefer short-lived delegated access over long-lived stored tokens
• audit every credential access
• revoke grants when tasks finish or user consent changes

Human approval

Require explicit approval or MFA step-up for sensitive actions.

Action	Recommended control
High-value wallet transaction	Budget, allowlist, freeze, and approval
Destructive API action	Delegated token with narrow scope and audit event
New third-party connection	Fresh consent
Long-running task finalization	Reconfirmation before execution
Organization ownership change	Human owner confirmation
Credential export	Policy denial unless explicitly allowed

Secure MCP servers

MCP servers should require OAuth access tokens. Validate audience, tenant, scopes, subject type, and delegation claims before executing tools.

For tool-level authorization, model each tool or resource family as a scope or policy-controlled capability.

Example policy shape:

Tool family	Scope or policy
Read project data	projects:read
Create ticket	tickets:create
Send message	messages:send plus user consent
Delete resource	Policy requiring human approval
Execute transaction	Wallet policy and budget check

Incident response for agents

If an agent behaves unexpectedly:

1. Suspend or disable the agent.
2. Revoke active delegated tokens and vault grants.
3. Revoke or deprecate affected keys and anchors.
4. Freeze managed wallets if wallet signing is involved.
5. Review audit events for agent access, delegation, vault, and wallet actions.
6. Rotate downstream provider credentials if the agent had access.
7. Re-enable only after policy and runtime changes are reviewed.

API surface

Agent management includes tenant-scoped routes for agents, anchors, keys, and delegations.

Route	Purpose
/api/v1/agents	Create, list, and manage agent records
/api/v1/agents/{agent_id}/anchors	Manage identity anchors
/api/v1/agents/{agent_id}/keys	Manage agent signing keys
/api/v1/delegations	Create and inspect delegations
/api/v1/delegations/{id}/revoke	Revoke delegated access
/.well-known/oauth-protected-resource	Discover protected resource metadata for OAuth-aware clients
/agents/{agent_id}/did.json	Hosted did:web document for an agent

Recommended reading

Related by summary, tags, categories, and content

Agent access should look like delegated work Model AI agent access as bounded delegated work with explicit scope, expiry, approval context, and audit-ready ownership. agents delegated access mcp Security Review tenant and end-user security controls for OAuth tokens, secrets, MFA, consent, agents, wallets, webhooks, and incidents. security checklist token validation mfa How SigID Works Understand SigID's tenant-local identity model, hosted auth, authorization, delegation, agents, webhooks, and audit controls. tenant identity global identity authorization