Use a connected external integration without exposing credentials to the agent

Outcome

A user can ask a named agent to perform an allowed operation through a connected external integration. The agent receives the result but never a provider credential, refresh token, authorization code, client secret, private key, or reusable signed authority artifact.

Proposed approach

• Mecatl requests one registered, typed operation from a protected authority service.
• The authority service verifies the caller workload, the user/owner, the named agent, the exact resolved target, and current policy.
• It reads or refreshes a provider credential only after allowing that exact operation.
• It invokes the provider and returns a sanitized result.
• The first proof uses one concrete integration (for example, GitHub through ToolHive).
• The existing remote mecabroker worktrack is candidate implementation material (see #1562). Direct remote access versus a local Unix-socket sidecar client remains an open packaging decision.

Not in this issue

Scheduled/unattended operation, broker high availability, generic HTTP proxying, unrestricted provider support, and returning provider tokens to Mecatl.

Dependencies

#478 where verifiable Mecatl agent identity is required, and a selected ToolHive release/capability set for the first integration.

Delivery issues

• #1562 — Integrate the remote protected-operation broker on current main
• #1563 — Enforce user, agent, and exact-target authority for the first ToolHive integration

Proof

• A read-only agent can perform its allowed read but cannot obtain write authority.
• An unapproved agent causes neither credential read nor provider call.
• The protected authority service resolves one exact target before policy and credential lookup.
• No provider credential or reusable authority artifact appears in a model prompt, tool result, event, diagnostic, log, metric, or trace.

Start by reading delivery issues #1562 and #1563, then review dependency #478 and the selected ToolHive capability set. Use the Proof section as the acceptance criteria: verify exact-target authorization, blocked unauthorized operations, and that credentials or reusable authority artifacts never appear in prompts, results, or telemetry.