Security and data
The relay counts calls. It does not read them.
Written for the person who has to sign this off, not for the person integrating it. Every claim here is something an auditor can check rather than something we would like to be true.
What happens to a request
Four hops. What each one sees, and what it keeps.
- 01Your agent
- Sees
- Everything. It is your data until it leaves your process.
- Keeps
- Whatever you keep.
- 02The relay
- Sees
- Headers, listing id, response size and status. Not the body.
- Keeps
- Metering metadata for 30 days. Never the request or response body.
- 03The creator's endpoint
- Sees
- The request body, in full.
- Keeps
- Exactly what their data-flow declaration says — which is on the listing page, before you buy.
- 04Back to your agent
- Sees
- The response, unchanged.
- Keeps
- Nothing in transit is retained.
Why there is a relay at all
It exists to make per-call billing possible, and for nothing else.
A creator selling professional judgement per call needs someone to count the calls, and a buyer needs that count to come from somewhere neither party controls alone. That is the relay's whole job. It also means a creator's own endpoint is never exposed to callers, so an endpoint cannot be scraped by anyone who has once paid for a single call.
Note
What the relay cannot do
The data-flow declaration
Every certified listing carries one, versioned, and shown before purchase.
This is the document that tells you what the creator does with what you send. It is a condition of certification, it is versioned, and a material change to it re-triggers review rather than quietly taking effect.
{
"version": "1.2",
"inputs": ["Structured case fields", "Free-text notes"],
"retention": "Request bodies discarded at response. Metadata kept 30 days.",
"processing_region": "United Kingdom (London)",
"subprocessors": [],
"trains_on_caller_data": false
}The last field is a filter on browse, and an enforceable organisation policy. If your answer to “may our inputs train someone's model” is no, you can make that structurally true for your whole team rather than a rule people are asked to remember.
Data residency
Where your account's data lives, and what happens when someone reaches across a border.
| Region | Primary store | Notes |
|---|---|---|
| United Kingdom | London | Default for UK-registered accounts. |
| European Union | Frankfurt | Default for EU-registered accounts. |
| United States | Virginia | Default for US-registered accounts. |
| Asia-Pacific | Singapore | Available on request at Enterprise. |
Cross-region reads are permitted where a lawful basis exists, and every one is recorded — actor, region, data region, timestamp — in an append-only log that Enterprise accounts can export for their own Article 30 records.
Posture
The controls, and where each one is checkable.
In transit and at rest
TLS 1.3 in transit. AES-256 at rest. Keys are rotated on a fixed schedule and on any suspicion.
Keys and scopes
Keys are scoped and shown once at creation. A read-only key literally cannot spend money.
Signed listings
Listing artefacts are signed with Ed25519. An unsigned or mis-signed artefact is refused at publish.
Append-only audit
Every operator action is written to a log that has no edit or delete path, retained seven years.
Kill switch
A listing or a whole category can be suspended immediately. Destructive actions need two operators and a TOTP.
Compliance
GDPR requests are tracked against the 30-day statutory deadline. SOC 2 Type II at Enterprise.
If something goes wrong
What we do, and how quickly you hear about it.
Commitments
- A confirmed breach affecting your data is notified within 72 hours, with what we know at the time rather than a finished report.
- A creator's lapsed certification suspends new purchases immediately and notifies existing subscribers the same day.
- A suspended listing returns a 409 with a reason rather than a generic failure, so your agent can route around it.
- Security reports go to security@vibestreet.io and are acknowledged within one working day.