Skip to main content
Akamai is a content delivery network that serves traffic from edge locations before forwarding it to your origin. EdgeWorkers runs your JavaScript at those locations. A responseProvider can read the request body, call another host, fetch the origin, and construct the response returned to the client. This integration evaluates requests to the AI routes matched by the EdgeWorker. It does not inspect origin responses, direct calls to model providers, or employee use of third-party AI services.

Integration capabilities

Before you start

Start with the policy in Observe mode. Findings appear in Activity without affecting traffic. Switch to Enforce after reviewing the results. See Policies.

1. Map the TrustGuard endpoint under your property

An EdgeWorkers httpRequest sub-request reaches only hostnames your Akamai property serves. A direct call to {TRUSTGUARD_URL} fails with a 400, so map the TrustGuard host as an origin on your property. In Property Manager, route a path on the property to the TrustGuard host as an origin:
The worker calls the relative path /trustguard/v1/evaluate, not the absolute URL. If you change the prefix, update both the property mapping and the worker.
The mapped path is a public route on your property. Any caller that can reach the property can reach /trustguard/*. TrustGuard rejects requests without a valid collector key, but the path remains an open proxy to the TrustGuard host until you restrict it in Property Manager. Do not rely on the key as the only access control for the route.

2. Write the responseProvider

Because responseProvider constructs the response, the worker must fetch the origin and construct the client response with createResponse, including for allowed requests. The allow path therefore makes two sub-requests. Both count toward the wall-time limit described in step 4.
Only POST is evaluated; every other method is sent to the origin with its original method. request.getHeader() returns an array, which is why header values use ?.[0]. Without it, the worker sends an array where POST /v1/evaluate expects a string.
This sample does not implement redaction. A transform verdict contains TrustGuard’s { "input": "…" } payload rather than your origin’s request schema. Applying it requires custom, schema-aware code that inserts the rewritten text into the original body. Until you implement and test that conversion, use Block rules.
The sample constructs the client response with the origin status and body, but passes an empty headers object to createResponse. Copy any required origin response headers into that object before production use.

3. Place the EdgeWorker after App & API Protector

Order the EdgeWorker behavior after App & API Protector on the property. The WAF then runs first. TrustGuard evaluates only traffic that App & API Protector accepts, avoiding an evaluation call for requests the WAF rejects.

4. Configure timeouts and failure behavior

An EdgeWorker has a 4-second wall-time budget, and it covers the guard call and the origin sub-request together, not each of them. The sample spends timeout: 3000 on the guard call, which leaves about a second for your origin. Measure your origin latency and set the guard timeout to leave enough time for both calls. The sample also has no try/catch. If TrustGuard is unreachable or the call times out, the worker throws and the property handles the failed EdgeWorker. Wrap the guard call and explicitly choose whether to continue to the origin (fail open) or return an error (fail closed).

5. Activate the bundle

Upload the EdgeWorker version and activate it on staging before production. The property version carrying the path mapping and behavior order has to be activated too, not just the worker.

6. Verify

  1. Put the policy in Enforce and POST a prompt to a guarded path that trips a rule.
  2. Confirm that the client receives 403 with the body Blocked by TrustGuard.
  3. Confirm the event in TrustGuard Activity, under the consumer_id you sent as X-User-Id.
Then send a clean prompt. Confirm that the client receives the expected origin status and body, and verify any origin headers that your implementation copies. The guard and origin calls together must stay within the wall-time limit.

Reference

Coverage

The integration evaluates input only and does not implement redaction. The 4-second wall-time budget covers both the evaluation and origin sub-requests. The sample also omits origin response headers when it constructs the client response.

What is evaluated

Every call is POST /v1/evaluate with the collector key as a bearer token, and the policy’s detectors decide the verdict. The worker acts on status alone: block becomes a 403, and other verdicts continue. The edge cannot prompt a user, so ask is allowed and recorded like report.

Configuration

Settings are defined in Property Manager and in the EdgeWorkers bundle.

Attributes

  • consumer_id: from the X-User-Id header. Per-consumer policy routing keys on it, and gates match it as consumer.id, so without it every caller shares the collector’s default policy.
  • session_id: from the X-Session-Id header. The sample sends "" when the header is absent. Send a stable, verified conversation ID if you need reliable grouping in Activity.
  • The edge derives neither. Your client has to send both headers, and getHeader() returns them as arrays, so take [0].

Troubleshooting