Getyn Security
Secure by design
Getyn helps teams create and manage AI-powered applications with protected credentials, controlled access, isolated workspaces and security-conscious workflows.
We publish what we do and what we do not do yet. Anything still in progress on this page is labelled as such.
Identity and access
Control who reaches each workspace
Access follows workspace membership and is re-checked on every request, by the database rather than by application code alone.
Account authentication
Sign in with email and password, or with Google when your workspace has it enabled. Sessions are issued and refreshed by our identity provider on every request rather than held indefinitely in the browser.
Workspace membership
People reach a workspace only by invitation. Invitations are single-use, tied to an email address, and can be revoked before they are accepted.
Project access is membership-scoped
Every request for a project is re-checked server-side against workspace membership, and the check is enforced by database policy rather than by application code alone.
Administrative surface
Our internal admin console is restricted to an explicit staff allow-list and returns a 404 to everyone else, so its existence is not discoverable. Every administrative action is recorded with the actor, the target and a timestamp.
What we do not offer yet: multi-factor authentication, federated single sign-on (SAML or OIDC) and directory provisioning (SCIM) are not implemented. They are on our roadmap, and we would rather say so here than let you discover it during a security review.
Credentials
Keep credentials protected
Secrets are read on the server and stay there. Interfaces report whether a value exists, never what it is.
Secret values never reach a browser
API keys, SMTP passwords and gateway credentials are read only on the server. The interfaces that manage them report whether a value is set — never the value itself — and audit entries record that a secret changed without recording what it changed to.
Per-app database keys are encrypted
When a project provisions its own database, the service key for that database is encrypted with AES-256-GCM using a unique initialisation vector per value, and the authentication tag is verified on decryption.
Project secrets are listed by name
The secrets manager inside a project returns the names of configured values so you can see what exists, without exposing the values to the interface.
Payment details never touch our servers
Card data is tokenised in the browser by our payment provider. We receive a token, never a card number, so card data is outside our systems entirely.
Data protection
Clear control over your application data
Row-level isolation, enforced by the database
Workspace data is separated by row-level security policies on the platform database. Access is decided by the database itself, so a mistake in application code cannot quietly widen it.
A dedicated database per app that needs one
When a project enables a backend it is provisioned its own Postgres instance — not a shared schema — with its own credentials and its own lifecycle.
Deny-by-default on sensitive tables
Infrastructure, metering and integration tables are readable only where a policy explicitly allows it, and several are reachable only by our own services with no client access at all.
Your code is yours, and portable
Any project can be exported to a repository in your own GitHub account. The output is standard React and TypeScript, so leaving is always possible and never requires our cooperation.
Platform
Protection across the platform
Separated build and serve paths
Generation runs in an ephemeral, isolated sandbox per project. Published sites are served as static artefacts from edge storage, so the build environment is not reachable from the public internet.
Signed webhooks
Our payment webhook verifies an HMAC-SHA256 signature over the raw request body using a constant-time comparison, and rejects any request that fails — including when no signing secret is configured.
Service-to-service boundary
The build engine is a private service. Browsers never call it directly; requests pass through our application tier, which performs the access check before proxying.
Reserved platform names
Hostnames that could be used to impersonate the platform or a brand surface cannot be claimed as project subdomains.
Being straight about monitoring: we do not yet run automated intrusion detection, request rate limiting or a formal uptime guarantee, and we have not commissioned an external penetration test. Those are real gaps rather than omissions from this page.
Lifecycle
Security at every stage
What protects you from signing in to operating a published application.
- 01Sign in
Credentials verified by our identity provider; a session is issued and refreshed server-side.
- 02Create a workspace
You become its owner. Nobody else can reach it until you invite them.
- 03Build an application
Generation runs in an isolated sandbox that is torn down afterwards.
- 04Connect services
Integration credentials are stored server-side and never returned to the browser.
- 05Configure credentials
Project secrets are listed by name; values stay on the server.
- 06Review and test
Every generation is a restorable version, so a change can be reverted rather than patched.
- 07Publish
A static artefact is built and served from edge storage under a slug you control.
- 08Operate
Traffic to your published site is visible to you; administrative actions on our side are recorded.
For builders
Security guidance for every builder
We secure the platform. These are the decisions that stay yours.
Grant the least access that works
Invite people to the workspace they need and remove them when the work ends. Access follows membership, so removal is immediate.
Keep credentials out of your code
Put API keys in the project's secrets rather than in a generated file. Anything written into your source is published with it.
Collect only the data you need
Every extra field is something you must then protect, justify and eventually delete. The cheapest data to secure is the data you never collected.
Separate what you test from what you serve
Use different credentials for a project you are experimenting with and one that real people rely on.
Review what you publish
Publishing makes a site reachable by anyone with the address. Check what is in it before you publish, not after.
Revisit integrations periodically
Rotate keys you no longer recognise and disconnect services you have stopped using.
Compliance and assurance
Where we actually stand
We hold no security certifications today. Rather than imply otherwise with badges, here is the real status of each framework.
GDPR & UK GDPR
Available nowA data processing agreement covering controller and processor roles, sub-processors, Standard Contractual Clauses for international transfers and breach notification.
Read the agreement →SOC 2 Type II
In progressOur controls programme is being prepared. No report has been issued and we do not claim SOC 2 compliance today.
ISO 27001
In progressWe are aligning our practices to the standard. We are not certified and no certificate exists.
HIPAA · PCI DSS
Not offeredWe do not currently offer a business associate agreement or handle cardholder data — card details are tokenised by our payment provider and never reach our systems.
Resources
Security resources
A sub-processor list and a written security overview are being prepared. Until they are published, email security@getyn.com and we will answer directly rather than link you to a page that does not exist.
Frequently
asked questions
Still stuck? Talk to us.
Platform data is held in managed Postgres, and published sites are served from edge storage. Applications that enable their own backend are provisioned a dedicated database, and the region for that database is recorded when it is created.
We do not currently offer selectable data residency for the platform database itself. If regional processing is a requirement for you, contact us before you build — we would rather tell you the position up front than after a procurement review.
Your prompts and project content are used to serve your requests — generating and editing your application — and are not used to train models.
Our formal AI data-handling policy is still being written. Until it is published we will answer specific questions directly rather than point you at a document that does not yet exist.
Credentials are read only on the server and are never returned to a browser. Management interfaces report whether a secret is set, not what it is, and audit records note that a secret changed without recording the value.
The service key for a project's provisioned database is encrypted with AES-256-GCM. Other stored credentials rely on the encryption provided by our database platform rather than an additional application-level layer — we would rather state that precisely than claim blanket encryption.
Workspace data is separated by row-level security policies enforced by the database, so the decision is not left to application code. Every project request is re-checked against membership server-side.
Applications that enable a backend get a dedicated Postgres instance rather than a shared schema.
Not yet. Sign-in today is email and password, or Google where a workspace has it enabled.
MFA is on our roadmap. We are not going to describe it as available before it is.
No. Federated single sign-on and directory-based provisioning are not implemented today, and access is managed through workspace invitations and roles.
These are among the most requested enterprise capabilities and are on our roadmap. If SSO is a procurement blocker, tell us — it helps us prioritise.
Yes. Any project exports to a repository in your own GitHub account, as standard React and TypeScript with no proprietary runtime.
Leaving does not require our cooperation or a support ticket.
Yes. Projects can be unpublished, which removes them from the public internet, and deleted from your workspace.
For deletion of an entire account and its associated data, contact us and we will action it.
Email security@getyn.com with enough detail to reproduce the issue. We will confirm receipt and keep you updated while we investigate.
Please give us a reasonable opportunity to fix an issue before disclosing it publicly. We will not pursue legal action against researchers who report in good faith, avoid privacy violations and do not degrade the service.
We do not currently run a paid bug bounty programme.
Our data processing agreement, platform rules and this page are published. For anything deeper — architecture detail, sub-processor lists, or a completed security questionnaire — contact us and we will respond directly.
We do not yet have a SOC 2 report or ISO 27001 certificate to share, and we will tell you that early rather than late.
Integration credentials are stored server-side and are never sent to a browser. Our payment webhook verifies an HMAC signature over the raw request body and rejects anything unsigned or mismatched.
An application you build reaches only the services you connect to it.
Remove them from the workspace and their access ends immediately, because access is evaluated per request against current membership rather than cached in a long-lived grant.
Pending invitations can be revoked before they are accepted.
Not today. The platform runs as a managed service.
Applications you build are a different matter: export the code and host it in your own environment whenever you like.
We are responsible for the platform: isolating workspaces, protecting stored credentials, securing the build and publish pipeline, and controlling our own administrative access.
You are responsible for what you build: who you invite, what data you collect, which integrations you connect, and what you choose to publish. The applications you create are yours, and so are the obligations that come with the data in them.
Build securely with Getyn
Create AI-powered websites and applications with controlled access, protected integrations and security-conscious workflows.