Security at Gyld
Gyld indexes your company's knowledge so your AI tools can use it. That only works if the data is protected like it's ours — here is exactly how.
Your company's knowledge stays yours
Your data is never used to train AI models, ours or anyone else's. Every workspace's brain is isolated from every other customer's, enforced both in the application and at the database itself.
Inside your workspace, content from Slack, Google Drive, OneDrive and SharePoint carries the permissions it had in the source: if someone cannot open a file there, they cannot see it through Gyld, and neither can an AI agent acting as them. Other connected sources do not expose per-document permissions to us, so what you index from them is visible per the visibility you choose for that connection. Your workspace admins can see everything in their own workspace.
Source permissions, mirrored
For Slack, Google Drive, OneDrive and SharePoint we read each item’s permissions from the source and enforce them on every query, including every AI-agent request. Checks fail closed: an unresolved permission shows nothing. Sources that expose no per-item permissions use the visibility you set for the connection.
Encrypted in transit and at rest
All traffic uses TLS and stored data is encrypted at rest. Credentials for connected accounts get a second, application-layer AES-256-GCM encryption on top, so a database leak alone does not expose a usable token.
Admin-controlled organization access
Org-wide installs use read-only scopes your IT admin approves in Microsoft Entra or the Google Admin console, and can revoke there instantly. Access tokens for org installs are minted on demand and never stored, so revocation is total.
Workspace isolation, twice over
Every page, memory and embedding is scoped to your workspace and membership is re-checked on every request. Underneath, the brain tables carry row-level security with no permissive policy at all: the public API key cannot read a single row, whatever the application does.
Three kinds of data, and nothing else
Indexed content
Pages, extracted summaries, and vector embeddings built from the sources you choose to connect — that’s the product. You decide what gets indexed, per source, and deletions in the source propagate to the brain. Disconnecting a source purges its indexed content.
Connection credentials
OAuth tokens for the accounts you connect, encrypted with AES-256-GCM at the application layer before they touch the database. Organization-wide installs store no tokens at all: access is minted per request from admin-granted consent.
Request logs
A record of every AI-agent request against your brain — which tool, which member, what was retrieved. These logs exist for YOUR visibility: they power your workspace’s activity dashboard and audit trail.
How we protect your data
- TLS in transit; encryption at rest for stored data
- Application-layer AES-256-GCM encryption for connected-account credentials
- Row-level security with no permissive policy on the knowledge tables, so the public API key can read nothing
- Per-item source permissions mirrored for Slack, Google Drive, OneDrive and SharePoint, enforced on every query and failing closed
- AI-agent (MCP) access bound to an individual member: the token is verified against our identity provider, and workspace membership and per-tool grants are re-checked on every single call
- Workspace admins get a kill switch and per-member usage caps for agent access
- Read-only, least-privilege scopes for organization-wide installs, revocable by your admin at any time
- Deletions in your connected sources propagate to the brain, and disconnecting a source purges what it indexed
- Database question-answering is read-only twice: the SQL is validated before a connection is opened, then run inside a read-only transaction that is always rolled back
- API keys are stored only as hashes, never in a form we could read back
- Outbound fetches resolve and re-check every address to block requests into private networks, on each redirect
- Content pulled in from email, chat and the web is fenced off as untrusted before any agent reads it
- HSTS, clickjacking, MIME-sniffing and referrer protections set on every response
- No training of AI models on customer data. OpenAI and Anthropic are used through their APIs, which do not train on API data
- Agent requests are logged to your own workspace audit dashboard
Who else touches your data
We use a set of infrastructure providers to deliver Gyld. Each processes data only as needed to provide their service. Which of these ever sees your content depends on what you connect and which features you use: an AI provider only receives what a query needs, and several below are involved only in a specific feature.
| Provider | Purpose |
|---|---|
| Vercel | Application hosting and compute |
| Supabase | Database, authentication, and storage |
| OpenAI | LLM inference via API (no training on API data) |
| Anthropic | LLM inference via API (no training on API data) |
| Moonshot AI | LLM inference for browser-driving agents |
| Cohere | Re-ranking of brain search results |
| Pinecone | Vector search |
| Composio | Connections to third-party app integrations |
| Firecrawl | Fetching and extracting web pages you ask us to index |
| Bright Data | Web retrieval infrastructure |
| E2B | Sandboxed code execution for agent tasks |
| Groq | Speech-to-text for voice input |
| ElevenLabs | Speech synthesis for voice output |
| Twilio | Telephony and SMS |
| Stripe | Billing and payments |
| Resend | Transactional email |
| PostHog | Product analytics and session replay |
Where we stand today
We follow GDPR-aligned data practices, offer a Data Processing Agreement on request, and are glad to complete security questionnaires as part of your review.
We are not SOC 2 certified. A SOC 2 program is on our roadmap and we would rather say so plainly than let a badge-shaped sentence imply otherwise. Ask us for our current posture documentation and we will send what we actually have.
Found something? Tell us
Report a vulnerability to curt@gyld.ai, or through the form below. We aim to acknowledge within two business days and will tell you what we found and when it is fixed. We will not pursue or support legal action against anyone who reports in good faith, gives us reasonable time to fix the issue, and does not access or modify other people's data while testing.
Questions about security?
Security review, questionnaire, DPA, or anything else — we answer directly and fast.