Canva AI Security and Prompt-Level Data Controls
Canva AI teams need evidence that connects each AI request to an authenticated actor, policy decision, and timestamp. This article separates provider administration records from independent request-layer evidence and maps the HTTP controls that regulated enterprises can verify during a security review.
TL;DR
- Canva AI security controls should connect each routed AI request to an authenticated actor, a policy decision, and a timestamp.
- Provider administration records support operations, while an independent request-layer record supports a later security or compliance review.
- The relevant control point sits in HTTP traffic between the application and the LLM endpoint.
The request record
An enterprise AI request begins when an authenticated user or agent sends prompt content through an application to a model endpoint. The request crosses a boundary before the model sees it. That boundary is where the security record has to start.
The record worth retaining identifies the acting principal, the route, the policy evaluated, the decision, and the event time. It should also make clear whether the request continued to the model or stopped at the control point. That distinction matters when someone is reconstructing a disputed action weeks later.
The resulting record is useful only if its fields describe one event.
A principal from one session, a policy version from another, and a timestamp copied from an application queue create a tidy-looking log with a broken chain of evidence. The request, its evaluation, and its outcome need a common event identity. That structure makes a specific request reconstructable after an incident, a customer inquiry, or a regulatory review.
Canva AI's documentation is the first source to consult for provider-specific logging and security behavior. The second source is the NIST AI Risk Management Framework, which frames governance as a set of documented practices rather than a dashboard setting. A 15-inch laptop on a review-room table can show a console log, but an auditor needs evidence that ties the log to the actual decision.
That evidence should answer a short sequence without requiring a meeting. Who acted? Which route did the request take? What policy was evaluated? What happened next? If the evidence requires an engineer to infer those answers from several systems, the review has become an exercise in reconstruction rather than verification.
Provider records and independent evidence
Provider logs can show account activity, configuration changes, and service events. Those records help the platform team operate the deployment. The request-level security question has a different shape: who initiated this prompt, what data classification applied, which policy version evaluated it, and did the model receive the request?
Those are different records with different owners. An administration record may show that a setting changed in Canva AI. A request-layer record shows what an authenticated actor sent through the application at a particular event time, what classification the control point assigned, and whether the request was permitted. Both records can be useful during an investigation, but they answer separate questions.
The distinction becomes visible during a simple review exercise. Select a request that was allowed and identify the actor, route, policy decision, and timestamp. Select a blocked request and perform the same check. The evidence should expose the decision path in both cases. A record that exists only for successful requests leaves the most important control outcome unproven.
I distrust an audit story that depends only on the same application that sent the prompt.
Application-owned logs can omit policy context or arrive after the response path has already completed. A decoupled control point records its own decision at the AI request boundary. The AI gateway architecture and audit-trail requirements explain the difference between a traffic control point and a general application log.
Independence also changes the timing requirement. The control point has to record the decision while it is handling the request, rather than waiting for the application to finish its own work. If the application crashes after the model responds, the independent record still needs to show what decision was made and when. That is the difference between an audit record and a post hoc summary.
Security review criteria
Review Canva AI against the HTTP path used in the deployment. Confirm which model endpoints the service covers, which identity context arrives with the request, and how a policy outcome is recorded. Then retrieve one permitted request and one blocked request by their timestamps. That exercise exposes gaps more clearly than a generic controls inventory.
Write the review around evidence, not screenshots.
For each sample, capture the request identifier, acting principal, destination route, policy version, classification result, decision, and event time. Check that the permitted sample shows the model path and that the blocked sample shows where forwarding stopped. The reviewer should be able to follow each record back to one request without relying on memory or a verbal explanation.
The same check should cover a response. Prompt controls describe what enters the model path, while response controls describe what returns to the authenticated user or agent. A security review that records the inbound decision but omits the response decision leaves the second half of the HTTP exchange unexplained. Keep the scope precise: the record concerns content that actually traverses the request boundary.
Ask one operational question as well: can the security team retrieve these records after the application has completed its work? If the answer depends on an application queue, a temporary console view, or a manually assembled export, the evidence is harder to verify. The request-layer record should remain available as its own account of the decision.
The scope also has a hard boundary. Local execution, device compromise, and stolen credentials fall outside a proxy that only receives HTTP AI traffic. Security teams need separate controls for those paths. The request boundary remains the correct place to enforce policy on prompt and response content that actually traverses it.
That boundary keeps the review honest.
A proxy can inspect the HTTP request and response it receives. It can bind the supplied identity to the policy decision, record the event, and enforce the result on that traffic. Separate controls still have to address activity that never reaches the proxy. The control claim should match the traffic the architecture can actually see.
DeepInspect
DeepInspect is a stateless proxy between authenticated users or agents and HTTP LLM endpoints. It evaluates identity-bound policy and prompt-level classification before the request reaches the model, then produces a per-decision audit record outside the application write path.
The record gives a review team a separate evidence source for the request it is examining. The actor, policy evaluation, decision, and event time stay attached to the same request boundary. A permitted request can be checked against the model route. A blocked request can be checked against the enforcement outcome. The architecture keeps those checks within the HTTP traffic DeepInspect receives.
For teams using Canva AI, this adds request-level enforcement and evidence without claiming to replace the provider's own controls. Book a technical deep dive at deepinspect.ai.