Give AI Agents API Access Without Exposing API Keys

To give an AI agent API access without exposing the target-system key, put a server-side execution gateway between the agent and the provider. The agent sends a bounded operation using a connection ID. The gateway validates the destination, method, and path, pauses consequential writes for approval, then adds the stored provider credential only when it dispatches the allowed request.

This pattern keeps the target credential out of prompts, tool results, and model-visible connection metadata. It does not make the credential disappear: the gateway must decrypt it and send it to the provider. It also does not help if the agent still has a direct API key, authenticated browser session, or another connector that reaches the same write operation.

ActionDock implements this pattern for compatible public REST APIs. Its first safe API write is intentionally narrower than a universal secrets platform or identity system.

Separate agent authentication from provider authentication

A brokered design uses two different credentials. Each authorizes a different relationship:

• ActionDock workspace API key — Held by the agent host or its secret manager. It authenticates the agent to ActionDock through MCP or HTTP.
• Target API credential — Stored in the ActionDock connection store. It authenticates an approved outbound request to the target provider.
• Connection policy — Enforced by the ActionDock server. It restricts the destination, HTTP methods, path prefixes, and execution behavior.
• Owner dashboard session — Held by the signed-in workspace owner. It authorizes approval or rejection of one exact external write.

The agent's ActionDock key is still a secret. It should be stored in the agent host's secret manager and never pasted into ordinary prompts. What the design removes from model context is the more consequential target credential: the bearer token or API key that can act directly on the business system.

When the agent lists connections, ActionDock returns non-secret metadata such as the connection ID, name, base URL, allowed methods, path prefixes, and whether a credential is configured. It does not return the credential itself. When a request is approved and ready to run, the server decrypts the credential and places it in either the Authorization: Bearer header or an owner-configured custom X-* header.

That is credential brokering, not zero-knowledge encryption. ActionDock can use the secret for the approved outbound request, and the provider necessarily receives it.

Keep provider-side privilege as narrow as possible

A gateway restriction is an additional authorization layer, not a replacement for provider-side permissions. If the target system can issue a key limited to one project, tenant, resource family, or write permission, use that narrower credential.

Google Cloud's official API key best practices recommend restricting keys, keeping them out of client code and repositories, isolating them, rotating them, and using a server that adds the credential to outbound requests. OWASP's Excessive Agency guidance likewise recommends minimizing tool functionality and permissions, avoiding open-ended extensions, and enforcing authorization outside the model.

Use both layers:

1. Provider layer: issue the least-privileged credential the target API supports.
2. Gateway layer: restrict the configured HTTPS destination, allowed HTTP methods, and path prefixes.
3. Transaction layer: bind the exact query and body into the approval preview before a write runs.
4. Operational layer: monitor use, rotate and revoke provider credentials, and investigate uncertain outcomes.

ActionDock does not currently create provider credentials, rotate them automatically, or integrate with a customer-managed vault or cloud IAM. Credential lifecycle management remains the owner's responsibility.

Method and path policy are not OAuth scopes

ActionDock's manual controls are simple and inspectable: one HTTPS base URL, an allowed-method list, and path-prefix rules. For example, a connection might permit GET and PATCH under /projects/ while blocking DELETE and paths under /billing/.

A path prefix is broader than an exact endpoint. /projects/ permits that resource path and its descendants. It does not express row-level authorization, field-level restrictions, or a JSON schema for the request body. The exact query and body are visible in the approval preview, but the default deterministic policy does not interpret their business meaning.

An optional reasonableness mode can evaluate an owner-authored rule against an approved write. That check is probabilistic and fail-closed. It is an additional gate, not a substitute for provider permissions or a guarantee that a payload is correct.

This distinction prevents a common overclaim: keeping a key server-side does not automatically make every use of that key least-privileged. The provider credential and the gateway policy must both be deliberately narrow.

SSRF controls belong in the credential broker

A service that accepts a destination from an agent and attaches a credential can become a server-side request forgery target. The broker must validate the network destination independently of the model.

The OWASP SSRF Prevention Cheat Sheet recommends allowlisting trusted destinations where possible, validating resolved addresses, and disabling redirect following so a validated request cannot be redirected to a different destination.

ActionDock applies the following controls to approved API connections and outbound requests:

• HTTPS only, on port 443.
• No embedded URL username or password, query, or fragment in the base URL.
• Publicly routed destination addresses only; loopback, private, link-local, and other special networks are blocked.
• The resolved public IP is used for the connection while the original hostname remains the TLS certificate name and HTTP host.
• Request paths must start with one slash and cannot use backslashes or decoded dot segments to escape the configured base path.
• Outbound requests do not follow redirects.
• Agents cannot add arbitrary outbound headers; ActionDock constructs the request and applies only the configured authentication form.
• Responses are limited to 1 MB and requests time out after 15 seconds.

These are SSRF protections, not a proof that SSRF is impossible. A public endpoint selected by an authorized owner can still be malicious or misconfigured, and future network or URL parsing vulnerabilities are always possible. The accurate claim is that ActionDock narrows and validates the outbound route rather than acting as an open credentialed proxy.

Where the current connection model fits

ActionDock's current connection model is deliberately narrow.

Supported

• Public HTTPS REST APIs on port 443
• Bearer-token authentication
• Custom X-* API-key headers

Technically supported

• APIs that require no authentication

Not currently supported

• OAuth-only user authorization
• Private-network or VPC-only endpoints
• Browser-only workflows
• mTLS
• Arbitrary authentication headers
• Custom request-signing schemes

This boundary is intentional: ActionDock currently works best with public REST APIs that accept a long-lived bearer token or API key. Workflows requiring browser sessions, user OAuth, private networking, or custom cryptographic signing need a different integration layer.

Bearer credentials are powerful because possession is sufficient to use them. RFC 6750 requires TLS for bearer-token use and discusses threats including token disclosure and replay. HTTPS protects the credential in transit, while server-side storage and provider restrictions reduce where it can be used.

If your target requires OAuth consent, short-lived workload identity, private connectivity, mTLS, or a provider-specific signature scheme, do not force it into a generic bearer/API-key connection. Those are product gaps today.

The gateway works only when it is the write path

Removing a credential from the model context is valuable, but it is not enough to establish a control boundary.

Suppose an agent submits writes through ActionDock but also has one of these:

• the original provider API key in another tool;
• an authenticated browser session with edit access;
• a native connector that can call the provider directly;
• shell or computer access to a host that contains the credential.

Any of those paths can bypass ActionDock's method, path, approval, and execution-state controls. ActionDock does not control an agent's browser, computer, reasoning, or actions outside requests routed through its MCP or HTTP API.

A trustworthy deployment removes direct provider credentials from the agent and uses provider IAM, network policy, host configuration, or organizational controls to make the gateway the only allowed route to the consequential operation. The MCP server security guide for write tools and the first-safe-write security model explain the wider boundary.

A credential-brokering checklist

Use this checklist before connecting a production API:

The final item matters because submission idempotency does not guarantee exactly-once provider execution. Read how ActionDock handles retries and execution_unknown before automating recovery.

Frequently asked questions

Does encryption at rest mean ActionDock cannot see the API key?

No. ActionDock decrypts the stored credential on the server so it can authenticate the approved provider request. The key is hidden from the agent, not from the execution gateway.

Does a server-held key replace provider IAM or key restrictions?

No. Use the narrowest provider-side credential available, then add ActionDock's destination, method, path, approval, and execution controls around its use.

What happens if the agent also has browser access to the provider?

The browser path bypasses ActionDock. Remove or externally restrict direct write access if ActionDock is intended to be the control boundary.

If you have a public REST write that fits this model, describe the blocked write. To configure an MCP or HTTP client without exposing the target credential, read the ActionDock agent guide.

Originally published at https://actiondock.app on August 28, 2026.