Allow an existing Answer account to be operated by an AI agent (personal access token, minimal scope)

首先定位现有的 session 或 API-key 身份验证路径，以及 account-settings 和 Admin → Advanced → Security 的入口点。在实现之前定义 token 的作用域和生命周期，然后验证基于 curl 的问题、答案和投票请求、撤销以及实例范围内的禁用是否会按规范使访问失效。

Background / Motivation

Users increasingly want their AI agents (e.g. Claude Code, Cursor, etc.) to act on their behalf on an Answer instance, asking questions, posting answers, and voting, using their own existing account. Today Answer only supports browser/cookie-based sessions, so there is no way for an agent to authenticate as "me" and perform these actions programmatically.

Stack Overflow's agents.stackoverflow.com is a related effort in this space, but it introduces a much larger system: a separate agent identity, reputation/trust scores, new content types such as Blueprints and Playbooks, and review gates. This proposal intentionally does not aim to replicate that. The goal here is the smallest possible change: let an agent drive an existing account through a token, with the same permissions and limits the account already has on the web.

Proposed minimal scope

Add a personal access token (or extend the existing API key mechanism, if one already exists) that a user can generate from their own account settings. Requests authenticated with this token act exactly as if the account holder performed the action via the web UI: same permissions, same rate limits, same anti-spam and moderation rules. It should cover the core write actions needed for basic participation: creating a question, posting an answer, and voting. Token management (create, view, revoke) lives in existing account settings, with no new roles or approval workflow. This capability is gated by a toggle under Admin -> Advanced -> Security, for example "Enable agent access tokens", which defaults to off. When disabled, the token-generation option is hidden from account settings and any previously issued tokens stop working, so an instance owner decides whether to expose this surface at all.

Explicit non-goals

This proposal does not introduce an agent-specific identity, badge, or "posted by an agent" marker. It does not add a new reputation or trust-score mechanism, and does not add new content types such as Blueprint or Playbook style posts. It does not change existing moderation, rate-limiting, or anti-abuse behavior; token-based actions should be constrained the same way web actions already are.

Acceptance criteria

A logged-in user can generate a personal access token from account settings. Using that token, for example via curl or an HTTP client, a caller can create a question, post an answer, and vote, with results identical to doing so via the web UI. The user can revoke the token at any time, immediately invalidating it. An instance admin can find the "Enable agent access tokens" toggle under Admin -> Advanced -> Security; turning it off immediately hides the token UI from users and invalidates existing tokens.

Open questions

Should token scope be all-or-nothing, or split into read/write (or per-action) permissions from the start? Should there be a way to visually distinguish agent-originated posts from human-originated ones in the UI? Neither is required for a first version.