Harness AI Security shares configuration, including the TPA endpoint, token, service name, and environment name, with the Harness WAAP plugin already attached to the same Route or Service. It doesn’t call the Traceable Platform Agent (TPA) directly.
Attaching Harness AI Security enables both request and response evaluation for that Route. The specific behavior for each direction is driven entirely by your platform rules.
When you enable this plugin on a Route, it acts in two Kong Gateway request-lifecycle phases:
-
access: Evaluates the request body against your configured rules, and redacts or blocks matching content before the request is proxied upstream.
-
response: Evaluates the complete upstream response body against your configured rules, and redacts matching content before it reaches the client.
sequenceDiagram
autonumber
participant C as Client
participant K as Kong Gateway
Harness AI Security
participant E as Edge Decision Service
participant U as Upstream AI service
C->>K: Request
Note over K: access phase
K->>E: Evaluate request body against rules
E-->>K: Redact, allow, or deny
K->>U: Request (redacted if matched)
U-->>K: Response
Note over K: response phase
K->>E: Evaluate response body against rules
E-->>K: Redact or allow
K-->>C: Response (redacted if matched)
Request evaluation, redaction, and blocking require mode: sync on the base Harness WAAP plugin config for the same Route or Service.
Response evaluation and redaction aren’t affected by the base plugin’s mode.
For more information, see the Harness WAAP plugin.
Harness AI Security buffers the complete upstream response before evaluating it.
If you attach the plugin to a Route serving Server-Sent Events (SSE) or other long-lived streaming responses, those responses won’t stream while the plugin is attached.
Large responses can also increase latency and memory usage while they’re buffered for evaluation.
The plugin evaluates request bodies only when the Content-Type header contains one of the following:
jsonxmlx-www-form-urlencodedtext/event-stream
It doesn’t evaluate other request body types, including text/plain, protobuf, gRPC, octet-stream, and images.
Request and response evaluation each default to fail-open (allow_on_failure: true).
If the Edge Decision Service is unreachable, times out, or returns an invalid response, traffic passes through without redaction.
Set allow_on_failure: false on request_config or response_config to fail closed instead.
When evaluation fails closed, or when a policy denies matching traffic, the client receives a 403 response by default.
You can customize the status code and message returned when the Traceable Platform Agent (TPA) blocks a request.
Configure this in the injector section of your TPA configuration:
ext_cap:
blocking_config:
response_status_code: 403
response_message: "Access Forbidden"
injector:
blocking_config:
response_status_code: 403
response_message: "Access Forbidden"
If you deploy the TPA with Helm, set the equivalent fields in values.yaml instead:
blockingStatusCode:
blockingMessage:
injector:
blockingConfig:
blockingStatusCode:
blockingMessage:
Note: response_status_code must be between 400 and 499.
If you set a value outside that range, the TPA falls back to the default status code, 403.
