Data Security on Archyl Cloud: What We Protect, How, and What We Don't Claim

Somewhere in your vendor questionnaire there is a row that reads "Is customer data encrypted at rest? Yes / No". For Archyl Cloud, the accurate answer is "yes, and here is exactly which fields". The text of your architecture (names, descriptions, ADRs, documentation) and your credentials are encrypted by our application before the database ever sees them. Uploaded files are encrypted by the storage provider. Identifiers, timestamps, diagram positions and account emails stay in clear, because the database has to index and join them. A vendor that ticks "Yes" without saying which is which is asking you to take the rest of the questionnaire on faith.

This post is the long answer. It covers what we encrypt and how, how data moves, who can reach what, what our AI provider receives, how we test, and what you can do under GDPR. It also says plainly where we are not yet: Archyl holds no security certification today.

Everything here is consistent with the Security Whitepaper (v3.0) and the Data Processing Agreement, both updated on 27 September 2026 and both linked from the Trust Center. If a sentence here and a sentence there ever disagree, tell us, because one of them is wrong.

The short version

For anyone filling in a form right now:

The rest of the post is the detail behind each row.

Encryption at rest, field by field

Archyl encrypts fields in the application, before they are written to the database. Every model that holds customer content carries a save hook that encrypts its text fields with AES-256-GCM on the way in, and a matching hook that decrypts them on the way out. Each encryption uses a fresh random nonce, so the same value stored twice produces two different ciphertexts.

That covers your architecture content, not only your secrets:

• C4 model: systems, containers, components and code elements (name, description, tags); relationships (description, tags)
• Architecture Decision Records: title, context, decision, consequences, tags
• Documentation: title, content, file path, tags; comments on it
• API contracts: name, description, content, endpoint, version
• Flows and whiteboards: names, descriptions, technology labels
• Also: overlays, event channels, insights, releases, conformance rules, change history and snapshots

And every credential and secret Archyl stores:

• OAuth tokens from GitHub, GitLab and Bitbucket
• API keys
• MFA secrets and recovery codes
• Integration and marketplace credentials
• Repository access tokens
• Cloud connection settings

This is always on. The encryption key is derived with Argon2id from a configured secret, and the server exits at startup if that secret is missing or shorter than 32 characters. There is no configuration in which Archyl runs and writes these fields in plaintext.

The practical consequence: a copy of the database on its own shows the shape of your data but not its words. The names of your services, the reasoning in your ADRs, the body of your docs, your GitHub token and your MFA secret all need the key as well.

Credentials also never come back out through the API. Integration settings are redacted on every read, so once you paste a key into Archyl, the interface can tell you that a key is stored, but it can't show it to you again, and no API call returns it to anyone else in your organization either.

What this does not cover

A database has to be able to find, sort and join rows, and it can't do that on ciphertext. So some fields stay in clear:

• Identifiers and the links between elements. The database knows that element A belongs to container B and has a relationship to element C. It doesn't know what any of them are called.
• Timestamps and diagram positions.
• Account email addresses and first and last names. Email carries a unique index, so two accounts can't claim the same address.

These fields are protected by the access controls described further down and by TLS in transit. This post makes no claim either way about disk-level encryption of the database.

Uploaded files

Files you attach to documentation (images, PDFs, other documents) don't live in the database. They are stored in Google Cloud Storage, and:

• Buckets are private. Nothing in them is publicly readable or listable.
• Files are encrypted at rest with AES-256 by Google Cloud Storage, with provider-managed keys.
• Files are served only through short-lived signed URLs. Each link grants access to one file and expires soon after it is generated, so a link copied into a ticket or a chat stops working rather than becoming a permanent public URL.
• The default region is the EU: Belgium, europe-west1.

Encryption in transit

Traffic between your browser, your tools and Archyl Cloud uses TLS 1.3. The connection from the application to its PostgreSQL database requires SSL, so the application does not talk to the database in plaintext.

Who can get in

People

• Multi-factor authentication uses TOTP, the six-digit codes from an authenticator app. Each MFA challenge can be used once, and recovery codes are stored as bcrypt hashes, so they can be checked but not read back.
• Single sign-on supports SAML 2.0 and OpenID Connect. Sign-in always starts at Archyl (SP-initiated only), and the state that ties your identity provider's response to that request is bound to the browser that started it and valid once. Our SSO post covers the setup.
• OAuth sign-in is available with GitHub, GitLab and Bitbucket.
• Changing your password or removing MFA revokes every older session. If you think a password has leaked, changing it signs out every other device that was using it.
• Password reset doesn't reveal whether an account exists, and a reset link stops working once it has been used.
• Login, MFA and password reset are rate limited, with limits layered so that a single IP, a single account or a single challenge can each only be tried so many times.

Machines: API keys and AI agents

• API keys are read-only by default. Write access has to be granted, and a key can be restricted to specific projects, so a key given to a CI job that only reads one project's model can do exactly that.
• The MCP server, which AI agents use to read and update your architecture, authenticates with OAuth and mandatory PKCE. Every mutation requires a write scope, so an agent you connected to answer questions about your architecture cannot change it unless you granted write access.

Tenant isolation

The failure every multi-tenant product has to design against is simple to describe: the server checks that you're logged in and belong to some organization, then trusts whatever identifier is in the request. Change the ID in the URL, and you're reading someone else's data.

Archyl authorizes every request against the resource it touches. Asking for a diagram, a document or a key means checking that the project or organization that owns that specific resource is one you have access to, not only that you're signed in. The same rule applies on the HTTP API and on the MCP server.

Two properties make this hold over time:

• Authorization fails closed. If ownership of a resource can't be determined, the answer is no.
• Automated tenancy tests run in CI and fail the build if an authorization check is removed, rather than waiting for someone to notice.

What the AI sees

Archyl Cloud's AI features use OpenAI, and no other AI provider, unless your organization configures its own key.

For architecture discovery, which reads a repository and proposes a C4 model, we send code signatures rather than source code. Here is a file as it sits in your repository:

package billing

import (
	"context"
	"github.com/stripe/stripe-go/v82"
)

type InvoiceService struct {
	Repo InvoiceRepository
}

func (s *InvoiceService) Finalize(ctx context.Context, id string) error {
	inv, err := s.Repo.Get(ctx, id)
	if err != nil {
		return err
	}
	if inv.Total > approvalThreshold {
		return ErrNeedsApproval
	}
	return s.Repo.MarkFinal(ctx, id)
}

And here is the section discovery builds for it, which is what goes into the prompt:

--- internal/billing/service.go [go] ---
Imports: context, github.com/stripe/stripe-go/v82
Types: struct InvoiceService,   InvoiceService.Repo InvoiceRepository
Functions: func (s *InvoiceService) Finalize(ctx context.Context, id string) error

The approval rule, the threshold and the body of Finalize stay out. What does go in: the repository name, the file and directory structure, and these signatures (imports, type and function declarations, exported constants). That's enough to work out that a billing component talks to Stripe. It isn't nothing, though: function and type names describe your system, so treat them as data you are sharing.

Two limits on that statement, so you don't read more into it than it says:

• It describes discovery's handling of source code. If discovery finds Architecture Decision Records written in Markdown in the repository, it sends their text so it can turn them into structured decisions, and it sends the opening lines of documentation files to give them titles.
• Other AI features send what their task needs. A coding agent, for example, works on the files it is changing, so it sees them.

If your policy says code can only go to a provider you have a contract with, organizations can bring their own AI key. AI requests then go to that provider, under your contract. If nothing may leave your network at all, a self-hosted Archyl can run models with Ollama on your own hardware.

How we test it

In the pipeline

Our CI pipeline runs four security scanners:

• govulncheck for known vulnerabilities in the Go dependencies we actually call
• CodeQL for static analysis of our own code
• gitleaks for secrets committed by mistake
• Trivy for vulnerabilities in container images and infrastructure configuration

In the platform

• Outbound requests are checked. Every integration that calls a URL you supply (a self-hosted Git server, a webhook, an AI endpoint) is protected against server-side request forgery, so that URL can't be used to make Archyl reach its own internal network.
• The browser runs only the scripts we ship. A strict Content-Security-Policy lists each inline script by hash, and scripts loaded from a CDN carry Subresource Integrity hashes, so a modified copy is refused.
• Containers are locked down. They run as a non-root user, on a read-only filesystem, with Linux capabilities dropped.
• Security events are logged, including failed logins, failed MFA attempts and rejected tokens.

Penetration testing

Between July and September 2026 we ran ten rounds of internal penetration testing. Every finding was fixed and covered by a regression test, so the same problem is caught if it comes back.

"Internal" means exactly that: we ran these tests ourselves, and no independent firm was involved. An independent penetration test is planned as part of the SOC 2 audit.

Your rights under GDPR

• Export. You can export your data as JSON.
• Deletion. Deleting your account deletes everything that belongs to it, cascading through your data and including uploaded attachments in object storage.
• A DPA for every customer. The Data Processing Agreement is available to all customers.
• Breach notification within 72 hours.
• 30 days' notice before any change to our sub-processors, so you can object before the change happens.

These are the sub-processors today:

The DPA lists the location and legal safeguards for each one.

What we don't claim yet

A security page that only lists strengths leaves you to find the gaps yourself. Here they are:

• No certification. Archyl is not SOC 2 certified and not ISO 27001 certified. For SOC 2 Type I, the readiness assessment is done and the independent audit is pending. ISO 27001 is planned. When an audit report exists, the Trust Center will say so; until then, nothing we publish should imply otherwise.
• No independent penetration test yet. The ten rounds described above were internal. The independent test comes with the SOC 2 audit.
• Not every column is encrypted. Identifiers, timestamps, diagram positions, emails and names stay in clear, as described above.

If your process requires a certification Archyl doesn't have yet, that is a real constraint and we'd rather you know it now than in week six of a procurement review.

Where to go next

• The Trust Center collects the documents in one place.
• The Security Whitepaper goes deeper on each control, including the rate limits and the security events we log.
• The Data Processing Agreement is the contractual version of the GDPR section above.
• For data-protection questions, or questionnaire items this post doesn't answer, write to privacy@archyl.com.
• To report a vulnerability, write to security@archyl.com. We acknowledge within 24 hours.

If you're the person who has to sign off on Archyl, we'd rather you found a precise answer to every question than a confident answer to most of them. Where something here isn't precise enough for your review, ask, and we'll make it precise.