You decide what is kept, where it runs, and what gets through.
Encrypted in transit and at rest. Logging you can turn off per key, or off for the whole organization. An EU gateway in Frankfurt. And a set of checks that refuse a request before any provider sees it.
Your prompts, on your terms
Logging is on by default, encrypted, in the EU, for 30 days. Turn it off per key and only metadata remains. Ask for organization-wide zero data retention and nothing is persisted at all.
- Per keyOff for the legal team, on for the sandbox
- Metadata still auditsTimestamp, user, model, tokens, cost
Keys that can only do what you said
TLS 1.2 or higher in transit, AES-256 at rest. Keys are hashed, shown once, and carry their own access list and spend cap. Service accounts give CI and agents a key that is not a person's.
Only from networks you trust
Set an IP allowlist for the organization, then narrow it further on any key. A request from anywhere else is refused at the gateway, so a copied key is useless outside your network.
- OrganizationOne list that every key inherits
- Per keyA production key that only works from production
- Addresses or rangesSingle IPs and CIDR ranges, on every plan
See who runs on each key, and catch the leaked one
For every key in the organization, admins see which coding agents, apps and SDKs use it, and who owns it. Four checks run over the last 30 days. A new tool and a traffic spike on the same key is flagged Critical, because that is what a leaked key looks like.
- New tool on the keyA client that has never used it before
- Traffic spikeAbout three times its normal volume
- Shared keyUsed by four or more different tools
- Unattributed trafficMostly requests that name no client
Expire a suspect key in one click and issue its owner a new one. Expiry can be undone, so acting fast costs nothing.
Your identity provider decides who gets in
Sign in with Entra ID, Okta, Google Workspace or any SAML 2.0 or OIDC provider. Once your domain is connected, email sign-in is off for it, so nobody bypasses your IdP. New people join on their first sign-in.
- Directory syncIdP groups stay in sync with Requesty groups of the same name
- DeprovisioningRemoving someone deletes their API keys and revokes access at once
- AuditedEvery sync change logged with the identity provider as actor
Three hops. Every check on the middle one.
Your application talks to the gateway in the region you chose. The gateway applies the organization's policy and forwards only what passes, only to the endpoints the policy allows.
Claims you can check
Each row names where the current status lives. Nothing here is asserted beyond what those pages say.
| Item | Status | Verify at |
|---|---|---|
| SOC 2 Type II | programme in progress | trust.requesty.ai |
| GDPR, Article 28 DPA | signed on request, any spend | sub-processors list |
| EU data residency | Frankfurt, eu-central-1 | requesty.ai/eu |
| Zero data retention | per key, or org-wide on request | docs |
| Encryption | TLS 1.2+ in transit, AES-256 at rest | trust.requesty.ai |
Questions security teams ask
Yes. All traffic is encrypted in transit with TLS 1.2 or higher, and all data at rest is encrypted with AES-256. Credentials and API keys are stored encrypted and never logged.
Requesty scans prompts and responses for personal data and secrets before they reach the model provider or come back to you. Each scanner is set to report or mask, organization wide or per group. It covers names, emails, phone numbers, SSNs, card numbers, and credentials such as API keys and database passwords.
Yes. Administrators can restrict the organization, or a group, to an approved list of models. A call to anything else gets a clear 403, and every attempt is logged for audit.
On self serve plans, prompt and output logging is on by default and retained for up to 30 days in encrypted form within the EU. You can turn it off per API key at any time. Organization-wide zero data retention, under which no prompt or output content is persisted and our own caching is disabled, is enabled on written request. Audit logs record metadata (timestamp, user, model, token counts, cost) in every configuration.
Our SOC 2 Type II programme is in progress. Current certification and audit status is published at trust.requesty.ai, and we make no representation of certification beyond what is stated there. We are GDPR compliant, provide a DPA on request, and support EU data residency in Frankfurt.
API keys are hashed at rest and shown in full only once, at creation. Administrators can rotate or revoke a key and set spend limits, access lists and an IP allowlist per key. Service accounts let you issue scoped keys for CI and agents without exposing a person’s credentials.
Yes, on every plan. Set an IP allowlist for the organization with single addresses or CIDR ranges, and narrow it further on any key. Requests from any other address are refused at the gateway.
The API Keys security view shows which coding agents, apps and SDKs use each key, named from the User-Agent and X-Title headers they send. Four checks run over the last 30 days: a new tool on the key, a traffic spike, a key shared by four or more tools, and mostly unattributed traffic. A new tool and a spike together is flagged Critical. Expire the key in one click; it can be undone.
Yes, on Enterprise. SSO works with Entra ID, Okta and any SAML 2.0 or OIDC provider. With directory sync on, IdP groups stay in sync with Requesty groups of the same name, and deprovisioning a user deletes their API keys so access ends immediately.
The controls are on every plan. Enterprise adds the paperwork.
SSO, a procurement process run by people, and a DPA on request.
Put the checks on the request path
Start on the same controls the largest teams run on.