The cloud's own AI services

If you are a single-cloud shop, and the people who have to check the evidence read that cloud’s logs from inside the account, use the cloud’s own service. It is already wired to the identity you use, it bills on the invoice you already get, and its guardrail service can be called for models the cloud does not host. The box at the end says which ones reach where.

The request it cannot take is for decision records in a SIEM that security runs, in an account the AI team does not own, with a way to tell whether anything is missing. That is post 4’s problem with the parties swapped.

Two ways of being in the path

A cloud guardrail decides at the moment of the call in one case: when it is attached to that cloud’s own model invocation, or to that cloud’s own gateway, so that the call physically passes through it. Bedrock Guardrails on a Bedrock model, Azure Content Safety as a policy on an API Management route, Model Armor in front of a Vertex endpoint. There, it is the process holding the connection, and it can do the four things.

In the other case, it is reached by API. An application, or a gateway from post 7, sends it a string and gets a verdict. AWS is explicit that its guardrail API works with any model, hosted anywhere, and Google lists half a dozen ways to call Model Armor from outside. That is a fine thing to offer. In that mode the service is a detector, the subject of post 9: it answers about the string it was handed, and deciding on that answer is somebody else’s job.

Both cases share one property. The record lands in that cloud’s logging, in CloudWatch or Azure Monitor or Security Command Center, in the tenancy that ran the call, under that tenancy’s IAM.

Custody, again

Post 4 argued that a marketplace’s record is kept by the party being checked. The cloud’s own service is the same argument from the other side. The record is kept by a party you are not paying on the purchase, which is better, but whose access control you do not own. A verifier outside the account is trusting whoever administers that account: that the retention was what they said, that the export was complete, that nobody with the right role tidied a log group. Inside a single-cloud shop, that verifier is internal audit reading the console, and the trust is fine. Across an account boundary, it is a signed statement from the tenancy owner, which is not what was asked for.

Who should use the cloud’s own anyway

The single-cloud shop, as above, with the verifier inside the account. Also anyone who wants a detector the cloud runs so they do not have to: a guardrail service reached by API is a good input, and pistra calls out to that kind of thing the way a gateway does. The difference is who holds the connection and where the record goes.

What pistra does at this box

Bedrock is one of the catalog presets. A provider pointed at it uses a bearer key out of the box, or, with aws credentials configured, signs each request with SigV4 as the last step after every other header change, so the signature covers what was actually sent. The record of what pistra decided goes to your collector over OpenTelemetry, whichever cloud served the call, on a synchronous exporter that counts every record the collector refused instead of dropping it. Where the decision record lives is then a choice you make, in an account you pick, and a command verifies the chain it is written in.

All posts