[bug] adapter tokens are not bound to adapter or integration identity

[nkanf-dev]

Problem

Adapter authentication is role-based only. Any bearer token in the adapter token set is accepted as adapter, but no adapter identity or integration identity is derived from that token.

The request body is then trusted for adapter_id and integration_id, and runtime behavior such as capability enforcement and approval channel routing is based on those caller-supplied fields.

That means one adapter with any valid adapter token can impersonate another adapter or integration when registering, requesting decisions, or reporting events.

Impact

• Coverage and registration state can be polluted by a different adapter using a borrowed/shared adapter token
• Capability checks can be evaluated against a forged integration id
• Approval requests can be routed to the wrong approval channel
• Audit records lose their value as authoritative evidence of which adapter actually made a request

Expected

Adapter authentication should bind requests to a concrete machine identity instead of only a role:

1. Tokens should map to a specific adapter identity, integration identity, or trusted principal set
2. Server-side identity should override or validate caller-supplied adapter_id / integration_id
3. Registration, decide, and report paths should use the authenticated principal, not only JSON body fields
4. Tests should cover attempted impersonation across integrations

Key code

• internal/authz/authorizer.go — tokens resolve to role only
• internal/httpapi/router.go — adapter endpoints only enforce the adapter role
• internal/core/engine.go — capability lookup and approval channel selection trust request integration_id

[nkanf-dev]

Fixed by implementing token-to-identity binding. Tokens can now be configured in 'token:id' format to restrict usage to a specific adapter or integration identity.