Problem

Robot accounts are deprecated in favor of API tokens, but the legacy CurrentRobotAccount(ctx) accessor (and its supporting middleware) still sits in usercontext and is the principal consumers read from across the attestation path. It survives only because of two compatibility bridges that stuff a partial RobotAccount into the context whenever the real principal is an API token or a user JWT.

The result is misleading code: callers think they're holding a robot account, but most of the fields on that struct are empty for the principals that actually drive traffic today.

Goal

Remove the deprecated robot account middleware and the CurrentRobotAccount helper, and migrate consumers to the proper accessors — entities.CurrentOrg(ctx) for the organization and entities.CurrentAPIToken(ctx) (nil-guarded) for API-token-specific claims.

Caveats — how CurrentRobotAccount(ctx) actually behaves today

The RobotAccount struct has four fields (ID, WorkflowID, OrgID, ProviderKey), but only the legacy real-robot-account path fills all of them in. Both compatibility bridges only populate OrgID and ProviderKey:

Consequences any migration needs to handle:

1. Only OrgID and ProviderKey are safe to read from CurrentRobotAccount(ctx). Reading ID or WorkflowID silently returns the zero value for two of the three principals.
2. entities.CurrentAPIToken(ctx) is only set when the principal is an API token. A naive swap of CurrentRobotAccount for CurrentAPIToken breaks user-token attestation flows (e.g., chainloop attestation init after chainloop auth login). We hit this regression in fix(controlplane): allow workflow-scoped API tokens in find-or-create #3123 — see that PR's iteration history.
3. There is no single drop-in replacement. The right replacement depends on what each call site actually needs:
   • Org → entities.CurrentOrg(ctx) (populated for all three principals).
   • API-token-specific claims (workflow scope, project scope, policies) → entities.CurrentAPIToken(ctx), guarded by a != nil check.
   • Robot-account ID / Workflow ID → only the real-robot-account path has these; for the other two, derive workflow/project info from the request or from entities.CurrentAPIToken claims.
4. Tests should explicitly cover the user-token path — this is the principal where regressions are easy to miss because it goes through neither of the two obvious middlewares (*RobotAccount* and *APIToken*).

Out of scope

• Removing the RobotAccountUseCase business logic and DB schema (handled separately as part of the broader robot account deprecation).