Allow skills to invoke NyxID services within user-delegated permissions

[louis4li]

Problem

The connected-service invocation path currently supports typed operations and recommended-skill/document guidance. Those capabilities are useful as a transition from existing OpenAPI-described APIs into skills, but they must not define the long-term authorization path or block a user from calling a service they are authorized to use.

The product goal is broader: users should be able to use any skill to call any NyxID connected-service API that falls within the permissions granted or defined for that service.

Goal

Make delegated service-relative requests the long-term connected-service execution path.

OpenAPI, MCP operation catalogs, operation_id, and corresponding recommended skills remain optional transition and guidance capabilities:

• They may help discover an API, load documentation, provide typed parameter guidance, or migrate an existing OpenAPI capability into a skill.
• They are not the permission source for a service.
• Their absence, temporary unavailability, or contract drift must not prevent an otherwise authorized delegated request.

Desired model:

service inventory + runtime credential scope
  -> delegated request admission
  -> NyxID credential-injecting proxy
  -> bounded result / effect receipt

optional transition paths:
  operation_id + live contract
  recommended skill/document guidance
  -> the same delegated proxy execution boundary

User Story

As a user who has connected or authorized a NyxID service,
I want any skill I use to call the service APIs that my authorization permits,
so that I am not blocked just because the service has no OpenAPI spec, no MCP catalog entry, or no generated recommended skill operation.

Execution Paths

Delegated service request (long-term mainline)

When a skill supplies a service identity and an explicit request:

• Resolve the current visible connected service by exact user_service_id or service_slug.
• Accept:
  • method
  • relative_path
  • optional query
  • optional non-sensitive headers
  • optional body
• Do not require OpenAPI, MCP, a recommended skill ref, or operation_id.
• Build a generic runtime admission for the authored request.
• Select credentials from runtime service binding state, never from skill text.
• Execute through the NyxID credential-injecting proxy.
• Return the normal bounded read projection or effect receipt.

Typed operation transition path

When operation_id is supplied:

• Resolve the current visible connected service.
• Use available live contract sources for schema and typed guidance.
• Apply the resolved typed admission when available.
• Execute through the same proxy, credential, receipt, and audit boundary.
• Contract discovery or recommended-skill state must not become the general service permission model.

Document/recommended-skill transition path

When a loaded recommended skill explicitly describes a request without a typed operation:

• Require the exact skill reference and digest for document provenance.
• Use the document only as request guidance.
• Enforce service identity, credential scope, request safety, risk, approval, audit, and receipt independently.
• Do not treat the skill document as a permission grant.

Required Runtime Boundaries

The runtime must enforce these boundaries for every execution path:

• The target connected service must be visible to the current sender/agent.
• The request must stay inside that connected service boundary.
• The request target must be service-relative; reject absolute URLs.
• Reject path traversal, fragments, and proxy-boundary escape attempts.
• Reject credential/transport headers such as Authorization, Host, and Cookie.
• Select credentials from runtime service binding state, never from skill text.
• Do not expose NyxID or downstream service tokens to skills.
• Infer request risk from method:
  • GET/HEAD/OPTIONS -> read-only
  • POST/PUT/PATCH -> write
  • DELETE -> destructive
• Preserve existing effect policy, approval, or user-delegated permission checks for write/destructive requests.
• Emit normal receipts/audit records.
• Treat downstream content as untrusted external data and keep bounded read results within the existing projection limits.

Permission Model

The permission source is the user's NyxID connected-service authorization and any Aevatar-side delegation policy attached to that service/sender/agent.

A skill, OpenAPI document, MCP catalog, or recommended skill is not a permission source. They may describe or guide a request, but runtime and NyxID decide whether the call is authorized.

Non-goals

• Do not allow arbitrary external URLs.
• Do not let skills handle tokens.
• Do not make recommended skill text authoritative for permissions.
• Do not require OpenAPI/MCP for delegated calls.
• Do not remove typed or recommended-skill transition support while it is needed for migration.
• Do not create a second proxy execution path that bypasses runtime admission, approval, audit, or receipt handling.

Acceptance Criteria

• A skill can invoke a connected service with no custom OpenAPI spec.
• A skill can invoke a connected service with no MCP operation catalog entry.
• A skill can invoke a connected service with no generated recommended skill operation.
• operation_id remains an optional typed transition path.
• Recommended skill/document guidance remains optional transition support and is not a permission source.
• All paths converge on the same credential-injecting proxy and receipt/audit boundary.
• Delegated mode rejects absolute URLs, path traversal, fragments, and proxy-boundary escapes.
• Delegated mode rejects credential/transport header injection.
• Delegated mode selects credentials only from runtime service binding state.
• Read-only delegated requests execute through the proxy and return bounded read projections and receipts.
• Write/destructive delegated requests respect existing effect policy, approval, and delegated permission checks.
• Tests cover sender-bound credentials and registration-agent-key credentials.
• Tests prove delegated mode does not fall back to unrestricted generic proxy behavior.
• Typed/document transition behavior remains covered without making it a prerequisite for delegated invocation.