Secretless OAuth Broker Arrives: Safer Workflow Automation for OpenClaw

TL;DR

This release adds a secretless OAuth broker that replaces stored API keys with just‑in‑time tokens for workflow automation. Tokens are minted per run, scoped tightly, and discarded after use so leaked environment variables and long config files no longer carry risk. The broker integrates with policies, audit logs, and our scheduler, which means safer rollouts without extra scripting. If you run OpenClaw jobs that connect to ad platforms, CRMs, or social APIs, this update reduces blast radius while keeping throughput high.

Why we built a secretless broker

API keys and long‑lived tokens became the default because they are simple to paste into environment variables. Simplicity is not the same as safety. Keys drift across CI systems, shell histories, or notebooks, and they rarely carry the least privilege required for a single automation. Rotating keys at scale is operationally expensive, and accidental exposure collapses trust quickly.

Our customers asked for a native way to eliminate most stored credentials without slowing teams down. The request was clear: keep the ergonomics of one‑click connectors, but issue short‑lived tokens on demand, record exactly who and what consumed them, and make migration easy. The secretless OAuth broker is our answer.

To see how this fits into the broader product, explore the AI marketing automation features on the feature set. If you are new to the hosted assistant, start from ButterGrow to understand how the platform packages OpenClaw for teams.

How the broker works end to end

At a high level, the broker sits between your connectors and the providers you authorize. It holds client credentials and refresh context in an encrypted vault, but it never hands these artifacts to a job directly. Instead, a job requests access for a specific connector and scope, the broker evaluates policy, mints a short‑lived token via OAuth, injects it into the call, then forgets it.

Step 1Connect a provider account

You start by creating a connection for a provider like Google, Meta, LinkedIn, or HubSpot. The connection wizard walks you through a standard OAuth consent screen. Scopes are pre‑filled by the connector, and you can remove anything that is not needed. The broker stores the resulting refresh context in the vault. No token or secret appears in your environment variables.

Step 2Authorize scopes with a policy

Each connection binds to a policy that limits what a job can request later. You can allow only read scopes for reporting pipelines or require a new approval for write scopes. Policies can also enforce time‑of‑day restrictions, IP allowlists for callbacks, or per‑project usage budgets.

Step 3Issue just in time tokens for each run

When a playbook runs, the connector asks the broker for a token. The request includes the connector id, the exact scopes needed for that call, and the run context. The broker evaluates policy, checks rate limits, mints a token, and streams it to the runtime over a secure channel. The token lives just long enough for the call. After the call ends, the runtime drops the token, and the broker forgets it.

Step 4Capture audit trails without exposing secrets

Every grant and token mint emits structured audit events. You will see who connected the account, which scopes were approved, which playbook consumed a token, and how the provider responded. These records appear next to run logs so incident reviews and compliance checks do not require another system.

Step 5Rotate and revoke with confidence

Because jobs never hold long‑lived credentials, you can revoke a connection or reduce scopes without redeploying environments. The next run will request a token with the new policy. If a token is suspected to have leaked, rotation takes effect immediately because minting is centralized.

Architecture at a glance

+-------------------+          +---------------------+          +--------------------+
|   OpenClaw Job    |  asks    |  Secretless Broker  |  calls   |   Provider OAuth   |
|  (Connector Call) | -------> |  (Policy + Vault)   | -------> |  (Token Endpoints) |
+-------------------+          +---------------------+          +--------------------+
         |                             |                                  |
         | receives short‑lived token  | evaluates scopes, budgets        |
         v                             v                                  v
   Provider API call            Encrypted refresh data              Access token mint

This approach reduces the time secrets spend in memory, avoids shell and CI exposure, and provides a single place to apply guardrails. It also keeps provider guidance front and center, such as short lifetimes for high‑risk scopes and rotation on use.

Security model and tradeoffs

We designed the broker to reduce blast radius without hurting throughput.

• Tokens are short lived. Typical TTL is 15 to 60 minutes depending on provider guidance. You can set a lower TTL per connector if needed.
• Scopes are minimized. The broker requests only the scopes a call declares. If a call asks for broader scopes than allowed, the request is denied and logged.
• Secrets are never injected into environment variables. Tokens flow over secure channels directly into the connector adapter, then the runtime forgets them.
• Audit events include scope, connector id, run id, and policy id. This creates a complete chain of custody for each call.
• Browser‑based consent remains user friendly, but it is now paired with policy enforcement so an errant playbook cannot escalate privileges silently.

Tradeoffs exist. Short‑lived tokens can increase token mint traffic if you have many small calls. We handle this with pooling per run and backoff when providers signal quotas. Another tradeoff is provider coverage. Most major platforms support OAuth well, but a few long‑tail APIs remain key‑only. For those, we isolate keys in the vault, rotate aggressively, and surface migration guidance when the provider adopts OAuth.

What changes for developers and operators

The broker is on by default for new OAuth connections. Existing jobs continue to work. You can opt into broker mode connection by connection and project by project. For teams that manage infrastructure as code, there is a new declarative block to define connections and policies.

connections:
  - name: google_ads_ro
    provider: google
    policy: reporting_only
    scopes:
      - https://www.googleapis.com/auth/adwords.readonly
  - name: meta_capi_write
    provider: meta
    policy: capi_uploads
    scopes:
      - ads_management

policies:
  - id: reporting_only
    max_ttl_minutes: 30
    allow_scopes:
      - https://www.googleapis.com/auth/adwords.readonly
  - id: capi_uploads
    max_ttl_minutes: 15
    allow_scopes:
      - ads_management
    require_approval_for_new_scopes: true

For operators, the most visible difference is in logs and approvals. Audit lines appear next to each run, and you will see policy decisions inline. You can route approvals into Slack using our content approval flows, and you can surface open questions in the answers to common questions section for teammates.

If you are evaluating the product, the features page shows how connectors, policies, and audit logs span the platform. When you are ready to try the broker, follow the onboarding flow. For a deep dive on operational posture, we also recommend the related post on protecting API keys and customer data with secrets management.

Provider coverage and flow selection

Most connectors now default to authorization code with PKCE for web flows and device authorization for headless environments. The broker detects the runtime and guides you accordingly. When a provider supports both, you can choose based on operator experience and endpoint capabilities. Device code flows are convenient for servers without browsers, while PKCE offers strong protections for interactive setups.

We publish a coverage matrix inside the connection wizard so you know which flows and scopes are available. If a provider only supports API keys today, we will highlight migration paths as they open OAuth routes. The broker plays well with partner ecosystems, so you can connect through customer data platforms or consent tools if that matches your stack.

Long‑tail phrase: secure OAuth flows for workflow automation

If you manage many jobs across teams, secure OAuth flows unify how access is granted. You can decouple human consent from machine runs, set policy controls at the connection boundary, and roll approvals into your change windows. This removes one‑off scripts, reduces bespoke secrets handling, and keeps compliance evidence in a single place.

Long‑tail phrase: how to rotate API keys in marketing automation platforms

For providers that have not shipped OAuth yet, you can still improve posture by rotating keys frequently. The vault issues time boxed keys with labels, you reference the label in your connectors, and the scheduler drains runs before changing labels. You can perform a shadow run that uses the new key while production continues to use the old one, then switch once results match.

Scheduling, quotas, and backpressure

Token minting interacts with scheduling. The broker coordinates with the runtime to respect provider quotas and backpressure. For example, if a provider returns headers that indicate a limit window, the scheduler slows down token mints and batches calls where possible. This reduces 429 errors and improves throughput consistency.

We also add per‑connector budgets. Budgets define maximum calls per minute or per hour, and they define per‑project or per‑workspace caps. Budgets prevent noisy neighbors within a workspace and keep third‑party relationships healthy.

Observability and incident response

Instrumenting credentialless access pays dividends when incidents happen. The audit feed shows every mint and every denial with reasons. You can filter by policy id, connector id, or run id. During an incident, you can revoke a connection, reduce scopes, or freeze a project. Because jobs never persist long‑lived secrets, these changes take effect immediately.

For postmortems, we include a replay guide. You can replay runs using the same inputs and the same policy to understand behavior without re‑consenting. Replay captures the exact scopes and policies that were in force at the time so you can reproduce failures faithfully.

Example: connecting a reporting pipeline

Here is a simple connector call that pulls daily spend from an ad account using the broker.

from openclaw import connect, run

conn = connect(name="google_ads_ro")

@run(schedule="0 5 * * *")
def pull_spend():
    report = conn.google_ads.query(
        resource="customer",
        fields=["metrics.cost_micros", "segments.date"],
        date_range="yesterday",
    )
    # process and send to warehouse

The code does not import a token or an API key. The runtime requests a token from the broker, the broker enforces the reporting_only policy, and the call executes with a short lifetime.

Migration guide

Step 1Inventory secrets in your projects

List every connector that uses a key or token. For each, note whether the provider supports OAuth today and which scopes you use. If you need help mapping scopes, consult the provider docs or the wizard.

Step 2Create connections and bind policies

Create a connection per provider account. Bind a policy that reflects the minimum privilege needed. Start with read scopes for reporting and add write scopes only for uploads.

Step 3Shadow runs before cutover

Enable shadow runs so the new connection processes the same events as production. Compare outputs, logs, and provider responses. When results match, flip traffic.

Step 4Roll out by project

Adopt the broker project by project. This keeps changes small and makes it easy to monitor impact. Use approvals for write scopes so changes stay intentional.

Step 5Remove legacy secrets

Once a project adopts the broker, remove keys from environment variables and secret stores for that project. This prevents drift and accidental reuse.

What this means for teams

You can now give teams fast access without giving them permanent secrets. Operators retain control through policies, approvals, and budgets. Developers enjoy simpler code and fewer environment variables. Security teams get traceable evidence without another appliance. The result is fewer incidents and shorter investigations.

ButterGrow runs this broker for the hosted product, and OpenClaw exposes the same capability for self‑hosted deployments. You can configure it from the UI or from code. The same policies apply to connectors across channels like ads, CRM, and social.

This launch is a foundation for automation that is easier to operate and safer to scale. It brings the security model closer to the way providers expect access to work, and it removes a class of credential incidents outright.

Our recommendation is simple. Start with connections that power reporting jobs, then expand to upload and sync tasks. Keep scopes tight and approvals explicit. Use budgets for high‑volume connectors. The broker does the heavy lifting so teams can ship faster with less risk.

Our roadmap adds richer policy language, better partner integrations, and more migration aids. We will continue to bring safety and speed together.

The feature is available today in all regions where ButterGrow runs, and it is included in all paid tiers.

The OpenClaw community can adopt this in self‑hosted deployments as well.

Your feedback is welcome. Tell us what worked, what was hard, and which providers you want next.

This update keeps automation flexible and safe.

Use it to protect access while you grow.

The next line is the call to action paragraph.

ButterGrow customers can try the secretless OAuth broker in their projects by following the onboarding flow in get started in minutes. If you want a tour first, the AI marketing automation features page shows how connectors, policies, and audit logs work together in context.

References

• OAuth 2.0 authorization framework (RFC 6749) - Specification that defines the core OAuth roles, grants, and token semantics that underpin modern API access models.
• OAuth 2.0 for native apps with PKCE (RFC 8252) - Guidance for native and desktop applications that use embedded browsers and public clients.
• OAuth 2.0 device authorization grant (RFC 8628) - Flow for headless and console environments that cannot launch a system browser directly.