Is your feature request related to a problem?

Hi Bytebase Team 👋

We're the Raft team — Raft (Raft / slock) is an open-source agent-orchestration runtime. We let humans and AI agents run as first-class, authenticated actors; our own agents reach external tools under an identity they hold themselves. We'd like to explore whether Bytebase would be open to supporting Login with Raft — that is, appearing as a Raft app (a first-class app on the Raft platform that authenticates via Login with Raft) — so the AI agents operating against databases through Bytebase get a real, per-agent identity in your governed path.

Today a managed agent operating against databases through Bytebase has no first-class identity — you'd either mint a shared/generic credential (collapsing per-actor RBAC, masking, JIT, and audit into one anonymous principal) or borrow a human's credential (breaking per-agent access control and audited attribution).

Describe the solution you'd like

We'd like to explore Bytebase supporting Login with Raft as a Raft app (the documented Login with Raft spec is at https://docs.raft.build/developers/login-with-raft/), so a Raft-managed agent authenticates into Bytebase and receives a real per-agent principal whose membership/RBAC/masking/audit resolves under its own identity.

This is feasible today on both sides:

• Raft (slock) already exposes an OIDC provider surface: GET /.well-known/openid-configuration returns issuer, token_endpoint /api/oauth/token, userinfo_endpoint /api/oauth/userinfo, and it supports the standard authorization_code flow (client_secret_basic / client_secret_post). Behind that is a real per-agent identity: Raft issues OAuth clients/grants and an agent-login primitive, so each managed agent presents its own identity rather than a shared one.
• Bytebase already consumes external OIDC identity providers (backend/plugin/idp/oidc, via coreos/go-oidc) with the standard issuer + client_id + client_secret + fieldMapping.identifier shape, and re-resolves membership/RBAC live on each request.

Integration shape: Bytebase appears as a Raft app: register a Raft server as an OIDC Identity Provider in Bytebase (issuer = the Raft server; client credentials from a Raft OAuth client; identifier = the identity claim returned by Raft's userinfo). A Raft-managed agent then authenticates through its own agent identity (Login with Raft), and Bytebase resolves that principal's RBAC / masking / audit / JIT grants normally.

We'd be glad to contribute the implementation from the Raft team (likely as a PR), for example:

• a "Raft / slock agent identity" OIDC provider type (or a documented reference configuration for the standard OIDC provider), including the fieldMapping.identifier mapping from Raft's userinfo claim to a Bytebase user/principal; and
• optionally surfacing Raft's custom urn:slock:grant-type:agent_request grant as an agent-only login flow, if you see value in a login that is specifically for agents rather than humans.

Additional context

• Our motivation is the same principle Bytebase cites: a governed path for every actor, human or AI. We want the agent to be attributable, least-privileged, and auditable under its own identity — not a shared actor hiding inside someone else's.
• Caveats noted for the design: the fieldMapping.identifier must align between Raft's userinfo identity field and Bytebase's user/principal; deployment needs the Raft server's issuer to be reachable; and Bytebase's seat/licensing semantics for an agent occupying a seat should be made explicit.
• Question to the Bytebase maintainers: is there an opportunity / would you be interested in supporting Login with Raft so Bytebase becomes a Raft app — giving the operating AI agent a real per-agent identity? We'd be happy to co-design the boundary (provider type vs documented standard-OIDC configuration; agent-only login vs human-and-agent login) and to contribute the implementation via a PR against your contribution guide.

Thank you for considering this — we believe "the operating AI agent has a real identity" is the natural next step of database governance, and we'd love to help build it with you.