Latte
8b7bb7205c
Inventory and gap analysis of the 0.2.0 codebase against the full Gitea API and the official gitea-mcp toolset, the B1..B11 + security chunk plan, ADRs 0001-0006 for the full-access rebuild, SDK/OAuth research notes, and the instance swagger pinned for tool generation. The audit-logging doc moves to docs/audit-logging.md.
1.5 KiB
1.5 KiB
ADR 0001: full access by default
Status: accepted (2026-10-14, owner decision)
Context
Until 0.2.0 the contract in AGENTS.md made writes opt-in (WRITE_MODE=false),
denied admin and credential endpoints by default, and emulated per-user rights
on a shared service PAT. The owner runs this server with a full-scope admin
token and wants every Gitea capability reachable through MCP: read, write,
secrets, admin and instance settings.
Decision
- Every tool generated from the Gitea API is enabled by default, including admin, secrets, deletes and Sudo.
- The server does not decide what is safe. The owner restricts exposure through
configuration (
READ_ONLY,TOOLSETS,DISABLED_TOOLS) and through the scope of the Gitea token they configure. - Kept invariants: audit event for every tool call, no secrets or tokens in
logs/errors/results, no stack traces by default,
127.0.0.1default bind, fail-closed HTTP auth (a non-loopback bind refuses to start without auth), untrusted-content labelling, schema validation with no extra properties, response size bounds. - Removed invariants: write opt-in, admin default-deny, the
gitea_requestdenylist and known-path gate, the resource-type authorization gate.
Consequences
A leaked MCP bearer token is equivalent to the configured Gitea token. That is
why HTTP auth is mandatory off-loopback and the token comparison is constant
time (see docs/security.md). The old AGENTS.md invariants are rewritten in
the same changeset.