Skip to main content

Solution brief: From AI detection to enforcement

This solution brief shows how to close the loop between AI observability and AI governance. Attribute™ delivers near real-time AI observability and attribution — it traces every token, inference, and training run back to the API key, workload, and customer that drove it. When Attribute detects something important — a runaway API key, an agent burning tokens unattended, a budget overflow — it invokes this CloudFlow via webhook. The flow validates the request, deduplicates it, obtains human approval, and revokes the offending API key against the right provider.

The problem​

AI adoption multiplies the number of long-lived credentials in your organization: OpenAI admin and project keys, Anthropic organization keys, Amazon Bedrock long-term credentials, Gemini API keys. Each one can drive real spend and real exposure — a leaked key, a misconfigured agent in a retry loop, or a workload that quietly outgrows its budget can burn through thousands of dollars before anyone looks at a dashboard.

Attribute solves the visibility half of this problem: it separates human from non-human traffic at runtime, allocates every token to the API key and workload that spent it, and catches anomalies — token spikes, runaway agents, budget overruns — in near real time.

But detection alone doesn't stop the burn. Acting on an Attribute alert by hand means locating the right provider admin console, holding standing credentials for four different provider APIs, and hoping the on-call engineer follows the runbook. There is rarely an approval step, and rarely a consistent audit trail of who revoked what, when, and why. Every minute between the alert and the revocation is money and exposure.

The solution​

Pair Attribute's detection with a CloudFlow enforcement endpoint. When Attribute identifies an API key that must be stopped, it calls the flow's webhook with the key's identity and the reason — and the flow takes it from there:

How Attribute and CloudFlow work together to revoke AI provider API keys

One request contract, four providers. The caller describes the key to revoke in a provider-neutral JSON payload. The flow translates it into the correct OpenAI, Anthropic, AWS, or Google Cloud API call, so the calling system never handles provider credentials or provider-specific APIs.

Validation before action. Every request is checked against a strict schema — supported provider, key kind, and provider-specific scope requirements. Malformed or unsupported requests fail immediately, before anything runs.

Idempotent by design. Requests carry a caller-generated request ID that is recorded in a ledger. Retries and duplicate deliveries never revoke a key twice.

Human approval before every revocation. No key is touched until a designated approver confirms the request from an email that carries the full context: provider, key ID, the reason Attribute raised, and the anomaly reference.

A built-in audit trail. Every request — executed, rejected, deduplicated, or failed — is recorded in run history with the output of each step, alongside the Attribute reference that triggered it.

The webhook contract is system-neutral, so the same endpoint also serves any other detection source — a secret scanner, a SIEM correlation rule, or your own governance service.

The flow combines a webhook trigger, Code, Datastore, Branch, and Switch nodes with approval-gated OpenAI, Anthropic, AWS, and Google Cloud actions:

The complete AI governance flow, from webhook trigger to the five provider revocation actions

Start from the template

This flow ships as a prebuilt template. In the CloudFlow template library, search for Revoke AI provider API keys via webhook and select it to create a draft flow. Then follow its built-in setup instructions: set the five flow variables (four provider connections and the approver email), create and select the request-ledger table, and publish.

How to build it​

The fastest path is the template — its README covers the full setup. The rest of this section explains what the flow consists of, whether you build it yourself or want to understand what the template contains.

Before you begin, you need:

  • OpenAI and Anthropic Admin API connections, plus AWS and Google Cloud permissions that allow key deletion in the accounts and projects you govern. Grant only the permissions required to revoke keys.

  • A Datastore table that serves as the request ledger, with a unique requestKey column.

  • An approver email address, and a DoiT API key for the calling system — Attribute or any other detection source. Treat the webhook URL and the API key as secrets.

The flow consists of four stages:

  1. Receive and validate: A webhook trigger accepts the JSON request, and a code node enforces the request contract (see How it works below). An invalid request fails the run with a descriptive error, and nothing downstream executes. Valid requests are normalized into a routing key such as openai.project.revoke.

  2. Deduplicate: A Datastore node looks up the request ID in the ledger table, and a Branch node separates new requests from replays. A new request is claimed in the ledger; a replayed request ends the run without any provider action.

  3. Route by provider: A Switch node matches the routing key against one case per provider route — openai.admin.revoke, openai.project.revoke, anthropic.organization.revoke, bedrock.bedrockLongTerm.revoke, and gemini.gcpApiKey.revoke. Exactly one case path activates per request. Because there is no Default path, a request that matches no case ends the run without side effects.

    Switch node configuration with one case per provider route

  4. Approve and execute: Each case path ends in a provider action that revokes the key — for example, the OpenAI admin-api-keys-delete action or the AWS IAM DeleteServiceSpecificCredential action. On each action, enable Require approval for this action, set the approver, and reference the request's provider, key ID, reason, and source reference in the approval message. Set an approval expiry so unattended requests reject automatically.

Test every provider route with disposable API keys before connecting Attribute or any other production system: publishing the flow immediately enables enforcement.

See also

The Switch node page uses this provider-routing pattern as its worked example.

How it works​

When Attribute detects an anomaly it attributes to a specific API key, it triggers the flow by sending a JSON payload to the webhook URL shown on the flow's trigger node, authenticating with a DoiT API key:

The webhook trigger configuration with the webhook URL and the sample request payload

curl -X POST "<webhook-url>" \
  -H "Authorization: Bearer $DOIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d @request.json

The payload describes one key to revoke:

{
  "schemaVersion": "1.0",
  "requestId": "attribute-anomaly-4711",
  "provider": "openai",
  "entity": {
    "type": "apiKey",
    "id": "key_abc123",
    "kind": "project",
    "scope": {
      "projectId": "proj_abc123",
      "accountId": "",
      "userName": ""
    }
  },
  "action": "revoke",
  "reason": "Runaway token consumption: key exceeded its daily budget by 12x",
  "sourceReference": "Attribute anomaly 4711"
}

  • schemaVersion: Must be 1.0.

  • requestId (optional): A caller-generated identifier used for deduplication — for example, the Attribute anomaly ID. Requests with a requestId that was already processed end without any provider action, so an anomaly that keeps firing never revokes a key twice. Requests without a requestId run on every delivery.

  • provider and entity.kind: Together they select the provider route. The supported combinations are:

    providerentity.kindRevokes
    openaiadminAn OpenAI admin API key
    openaiprojectAn OpenAI project API key (entity.scope.projectId required)
    anthropicorganizationAn Anthropic organization API key
    bedrockbedrockLongTermA Bedrock long-term credential (entity.scope.accountId must be a 12-digit AWS account ID; entity.scope.userName required)
    geminigcpApiKeyA Gemini API key (entity.id must be the full resource name projects/<project>/locations/global/keys/<key>)

  • entity.id: The provider-side identifier of the key to revoke.

  • action: Must be revoke. The flow deliberately supports a single, well-understood verb; broader vocabularies (suspend, disable, delete) map onto provider-specific semantics that deserve their own explicit routes.

  • reason and sourceReference (optional): Free-text context that appears in the approval email and the audit trail. Attribute populates these with the anomaly description and its reference, so the approver sees exactly why the key was flagged.

The endpoint responds immediately with a link to the run in run history; the outcome is recorded there:

RequestOutcome
Valid, new requestIdRun pauses at the approval step; the key is revoked after approval
Replay of a processed requestIdRun completes without any provider action
Approval rejected or expiredRun completes without any provider action
Unsupported provider, kind, or actionRun fails at validation with a descriptive error; nothing executes

Note that CloudFlow runs one execution of a flow at a time. While a request is waiting for approval, new webhook deliveries to the same flow are rejected with a 409 Conflict response, and the caller should retry later. Keep the approval expiry window short if you expect frequent requests.

Seeing it end to end​

This pattern is most useful when the detection side is already in place. If you'd like to see how Attribute™ surfaces the anomalies that trigger this flow — token spikes, runaway agents, and per-key spend attributed back to the workload — and walk through wiring it to CloudFlow for your own environment, you can book a walkthrough.

See also​

Last updated on