Platform Gateway

Three Separate Pieces

AP keeps three concerns separate:

That split is the core trust boundary. A session never gets a raw integration token just because a connection exists.

This is also where AP "skills" fit today. A skill is just a capability grouping built from available actions and integrations in the current workspace. It is not a separate runtime, installable agent, or prompt pack.

Action Flow

session or ap do
    -> choose action
    -> resolve visible connection for the current workspace
    -> load encrypted credential from the AP vault
    -> check permission grant
    -> execute read-only provider call
    -> persist action invocation audit record

What the Gateway Exposes

The gateway only exposes read-only actions today. The current bundles cover Slack, Linear, and Google Workspace providers. Actions become executable only if:

1. The current workspace can resolve a valid connection.
2. The current user or role is allowed to use the action.

If a connection is revoked or requires reconnect, the action disappears from the executable surface.

Permission Behavior

Admins are implicitly allowed to use every read action.

For members:

• User-private connections automatically seed matching owner grants.
• Shared connections still need explicit grants if you want non-admin users to use them.
• Grants can be scoped to one workspace or to the whole organization.

Audit Trail

Every gateway execution records an invocation row with:

• Session ID, when one exists
• User, organization, and workspace
• Action and resource
• Permission used
• Connection used
• Input keys
• Status, error, and duration

That same audit data powers ap actions invocations and the dashboard activity panels.

Model Calls Are Separate

Interactive model execution does not go through the action gateway. The control plane uses the platform-hosted model configuration directly for session runs, while the AP vault remains dedicated to integration credentials.