Security
SysJ never holds a key to your cloud.
How it is built
Controls in the architecture, not bolted on.
Cloud access
Delegated, short-lived and yours to revoke.
On AWS you create a role that trusts SysJ with an external id unique to your workspace. Google Cloud uses Workload Identity Federation and Azure uses federated credentials. SysJ assumes access for the length of a run and stores no long-lived secret.
- External id per workspace prevents confused-deputy access
- Changes scoped to resources SysJ tagged
- Revoke by deleting the role, without asking us
Change control
Every change is a plan that policy and a person approve.
Policy reads the real Terraform plan and refuses unsafe networking, identity and data settings. A person with the right permission approves, and the approval is bound to the plan’s digest so nothing else can be applied under it.
- Separate permission for destructive changes
- Typed confirmation for anything that deletes
- Production protected from deletion by default
Isolation
A database and an identity realm for every workspace.
Isolation is physical rather than a column in a shared table. Each workspace has its own Postgres database and its own identity realm, and a token issued for one is refused by every other on its issuer and signing key.
- No shared tables between customers
- Permissions checked on the server on every request
- Revoked grants take effect on the next request
The AI boundary
The model proposes. It never acts.
SysJ is designed so that a cleverly worded prompt cannot change what the system is allowed to do.
No path from model output to your cloud
The model chooses modules and parameters inside a typed graph. Terraform is rendered by code, and nothing is applied without an approved plan. The worst a manipulated model can do is propose a plan you reject.
The assistant acts as you, never as itself
The assistant holds no credential of its own. Every call it makes carries your permissions, so it can never do what you could not.
No channel to leak through
The assistant cannot fetch arbitrary URLs, and its replies render without remote images or automatic links, so injected content has nowhere to send your data.
Your data enters as data
Content from your workspace reaches the model only as bounded tool results, never as instructions, and conversations are stored in your workspace database.
Platform
How we run SysJ itself.
Secrets in a vault
Platform credentials live in a secrets manager, never in code or images, and secret scanning runs on every commit.
Signed, non-root images
Services run as non-root containers, and only images signed by our build pipeline are admitted to the cluster.
Dependency audit
Every repository is audited for vulnerable dependencies on each commit, and a high severity finding blocks the change.
Errors that leak nothing
Error responses carry a code, never a driver message, so a connection string or token cannot reach a log or a browser.
An append-only record
Every request, approval and change is written to a log that is added to and never edited.
If we are down, you are not
Your infrastructure, state and deployments live in your accounts, so they keep running whether or not SysJ is reachable.
Responsible disclosure
Found something? Tell us.
If you believe you have found a security issue in SysJ, contact us and mark it as a security report. A person reads every report and replies.
See your own infrastructure as a plan.
Tell us about your team and the cloud you use. We will set up your workspace and walk through your first plan with you.