We Put an Autonomous AI Inside Your Product and Your Prospect's Meeting. Here's What Happens to the Data.

Most security pages start with logos — a wall of compliance badges meant to end the conversation before it starts. We'd rather start it. Because if you're evaluating an AI agent that runs live demos, you already know the badges aren't the hard part. The hard part is what the thing actually touches.

So let's be specific about the trust surface, then walk through how each piece is handled.

Name the surface honestly

A Xebit demo agent, over the course of a single session, may: log into your product, drive a live browser session inside that product, join a video meeting with an external prospect, record and transcribe that meeting, and store the resulting artifacts. That is a lot of sensitive ground — your application credentials, your prospect's words, a recording of a real conversation. Pretending otherwise would be the wrong way to earn trust. Here's how each is contained.

Credentials: encrypted, scoped, and never in the logs

Any credential the agent needs to access your product is encrypted at rest — secrets are never stored in plaintext. Just as importantly, access is scoped per demo: a demo session gets an isolated browser session with its own state, and any tokens captured to drive that session are bound to it, not pooled or shared across demos.

And one practice we hold as a hard rule: URLs that carry credentials are never written to logs in full. The most common way secrets leak isn't a breach — it's a credentialed link sitting in a log file someone forgot was sensitive. We engineered that failure mode out. The system is built so that the convenient-but-dangerous act of logging a full credentialed URL simply doesn't happen.

Isolation and tenancy: your data stays yours

Every customer's data is organizationally scoped at the data layer — queries are constrained to the requesting tenant, so one customer's sessions, transcripts, and configuration are not reachable from another's context. At the demo level, each session runs with its own isolated browser state rather than a shared, long-lived environment, so one demo can't inherit another's session, cookies, or logged-in state. Isolation isn't a setting you opt into; it's the default shape of the system.

Recordings and transcripts: where they live, and for how long

When a demo is recorded and transcribed, those artifacts are stored in managed object storage (Amazon S3) under controlled, prefixed paths — not scattered across ad-hoc locations. That gives you a single, governable place to reason about retention, access, and deletion. You should align retention and access controls to your own policy, and the architecture is built to let you do exactly that rather than locking you into ours.

Consent matters here too, because these are recorded conversations with real people. The platform includes explicit consent, terms, and privacy surfaces so the recording posture is disclosed and defensible — not an afterthought bolted on after legal asks.

What we log — and what we deliberately don't

Good observability and good security pull in opposite directions, and we resolve the tension on the side of restraint. The system logs what's needed to operate, debug, and audit the agent's decisions — state transitions, external calls, the why behind a given action. It deliberately does not capture the sensitive payloads that would turn a log file into a liability: credentials, full credentialed URLs, and the secrets that flow through a demo session. The principle is least-exposure: log enough to be accountable, never enough to be dangerous.

Security for a customer-facing AI is an architecture claim before it's a certification claim. The badge tells you someone checked. The architecture tells you what they'd find.

Compliance posture

On the formal side — certifications, data-processing terms, data residency — we share our current posture directly with your security team as part of any evaluation, in the detail a real review needs. We'd rather hand you the specifics under review than reduce them to a badge on a marketing page.

And the point of this post stands on its own: we'll hand your security team the data-flow diagram, the encryption and isolation model, the retention controls, and the logging boundaries — and we'll do it early, because a deal that stalls in security review is a deal you've already half-lost. We'd rather answer the questionnaire before you send it.