Security
Security built around independent oversight.
Vraelis judges work that agents produce, so the party doing the work is never the party that approves it. This is how access, secrets, and evidence are handled today, and an honest account of what is not yet in place.
The model
Access maps to who should have it, and the judge is separate from the builder.
Three principles sit under everything below: scope access to the right people, keep sensitive duties apart, and give a run the least authority it needs.
Owner-scoped access
Every connected application carries an explicit owner, and an I own or authorized this confirmation is required before a run can touch it. Access is scoped to the people and identities that should have it, not opened to anyone who can reach the system.
Separation of duties
A billing admin manages payment without owning data or members, and ownership transfer is a deliberate, guarded action. In the same spirit, the agent that builds a system does not approve its own proof; completion is judged on independent evidence.
Least authority over your environment
You choose what a run can reach. Point Vraelis at a preview or staging deployment and keep external services in test mode. Vraelis drives the app from the outside, so a run touches only what that environment already touches.
System status
What is operational.
An honest read of what you can use today, what is in preview, and what is committed but not yet live.
Operational means available to use today. Preview means present but not enabled for sign-in. Planned means committed direction, not a live feature.
Architecture and data handling
What we store, and how it is protected.
These are the controls in place now. Each one is a specific decision about where data lives and who can reach it.
Owner-authorized signed URLs
Screenshots and traces live in a private bucket. No public URL is ever produced. Reads go through short-lived signed URLs that only an authorized owner can mint.
Secrets encrypted at rest
An organization's OIDC client secret is encrypted at rest with AES-256-GCM. It is never returned to the client and never written to logs.
DNS tokens are hashed
Domain verification stores only the SHA-256 of the DNS TXT token. The raw token is shown once and never persisted.
Sanitized audit export
Governance activity exports as CSV or JSON against a whitelist of safe fields: no secrets, invite or DNS tokens, token hashes, Stripe identifiers, API keys, OIDC codes, SAML assertions, certificate bodies, full URLs, or IP and device data.
Validated OIDC sign-in
The id_token is validated on signature, issuer, audience, and nonce, and the email domain must match the verified organization domain before access is granted.
Governed domain provisioning
A verified-domain match maps a user into the organization at a safe role. It never grants workspace, project, billing, or API access on its own.
Payments isolated to Stripe
Card data is processed by Stripe. Vraelis never sees card numbers. Your billing overview stays in Vraelis.
The builder does not self-approve
An agent cannot mark its own work trusted. Proof comes from exercising the running software and computing a decision on the evidence, not from the agent's report.
Identity
Single sign-on, described honestly.
What is live today, and what is still a direction. We separate the two rather than blur them.
- OIDC single sign-onAvailable
Organizations can configure OIDC for any verified domain, with full token validation and a domain-match requirement before a user is admitted.
- SAML single sign-onPreview
The SP metadata endpoint exists, but assertion sign-in is not enabled yet, and we do not present it as if it were.
- SCIM provisioningPlanned
Automated provisioning and deprovisioning is planned for larger organizations. It is not live today.
- Domain provisioningGoverned
A domain match maps users into the organization at a safe role and never grants elevated access by itself.
Honest limits
What we do not claim.
We describe what Vraelis actually does. We do not claim formal certifications, and we do not display compliance seals.
- No formal compliance certifications. Vraelis is not SOC 2 certified, and we will not display seals we have not earned.
- SAML sign-in is in preview and SCIM is planned. Neither is presented as live.
- Scheduled audit exports and retention controls are a direction, not a built feature.
- Vraelis assesses and oversees. It is not a guarantee, and it does not replace your own security review of the environment you point it at.
If your organization needs specific compliance attestations, talk to the team about requirements before you rely on Vraelis for them.
Oversight you can inspect, not take on faith.
The same standard we hold agent work to is the one we hold ourselves to: describe what is real, and show the seams.