Limits: sign-in, agent keys, Stop and intents

The limits of sign-in, agent and admin keys, Stop and signed intents, including where rate limits live and what Stop cannot undo.

Identity limits (S07)

Sign-in needs the email inbox, or an operator. There are no passwords, no SSO or SCIM yet, and no self-serve signup. Without a mail provider, operators issue links with deedglass org login-link.
Rate limits live in each server process. Behind N instances a client gets up to N times the IP and email budgets; the per-user cap on new sign-in tokens is counted in the database.
A newer sign-in email voids older links in its own org only; a link into another org stays usable until it expires (15 minutes).
Unknown addresses and wrong codes take similar, not identical, time (a dummy hash is computed when there is nothing to compare; the number of database reads differs).

Test keys aren’t enforced against connectors. A dg_test_ key carries livemode: false and is recorded on each action from S13, but connectors have no test mode in v1, so a test key can reach a live system. Enforcement waits for connector modes (v0.2).
The failed-auth limiter lives in each server process. Behind N instances, a client gets up to N times the per-address and per-prefix budgets.
While an org is stopped, its admin keys can only read (GET). Every request from them that changes state gets org_stopped. Changing agents during a Stop all needs a Console session or the operator CLI.
Stop can’t un-run an action already executing at a tool. It refuses new calls and, from S13 and S22, queued and approved work; a call a tool already received happens.
The 2-second Stop bound assumes every instance can reach Postgres. If Postgres is down, no agent can act at all: Deedglass fails closed.
Agent keys’ deed reads filter on body->'agent'->>'id' without an index. Fine at v1 volumes; in a large org, an agent key listing its deeds reads more rows than it returns.
Key lists show at most 100 keys per agent (and 100 org admin keys), newest first, revoked ones included. There is no pagination yet.

MCP clients can’t sign intents in v1. An agent in required mode can act only through the SDKs or the REST API (INTENTS.md).
A compromised runtime holds both keys. Whoever controls the process that signs holds the API key and the intent key, and acts as the agent. Intents can’t help there; policies, approvals and Stop still apply.
Unsigned on-behalf-of is a claim. Deedglass-On-Behalf-Of and Deedglass-Session are recorded as the agent sends them. A signed on_behalf_of is bound to the agent’s key, but Deedglass can’t know the person is real until v2 checks tokens from your identity provider.
No authorization server in v1. MCP clients authenticate with pre-issued API keys as bearer tokens; the protected-resource metadata omits authorization_servers on purpose, so clients that can only do OAuth can’t connect yet (MCP_AUTHORIZATION.md).
Intent modes are enforced from S13. In S09 the checks answered only POST /v1/intents/verify; since S13 the Gate checks the header on every POST /v1/actions.
A valid intent works once for whoever holds it, within its window (at most 5 minutes plus 60 seconds of skew). The nonce stops the second use, not the first.
Intent keys don’t expire. A registered key works until it is removed.