Credential Security Architecture

vCISO Lite reads your cloud, identity and code platforms to check your controls and, only when you allow it, makes changes you approve. Part I covers how a secret is stored. Part II covers the separation between reading and writing. Part III goes platform by platform. Part IV is what happens when something goes wrong, and what stays in your hands.

Every value gets its own key

We use envelope encryption. When you connect a platform, the secret it gives us (an API token, an OAuth token, a private key) is encrypted with a fresh, random 256-bit data key used for that one value and nothing else, using AES-256-GCM.

The data key is then sent to Google Cloud KMS, which encrypts it with a key-encryption key that never leaves KMS. We store the encrypted data key next to the ciphertext, and the plaintext data key is wiped from memory as soon as it has been used.

scope the one connection this value belongs to wrapped key the data key, encrypted by Cloud KMS nonce random, used once ciphertext the secret, encrypted with the data key (AES-256-GCM)

Bound to the connection it belongs to

Both layers carry the connection the value belongs to as authenticated data. Change that binding, or copy the value into another connection's record or another customer's, and neither layer will decrypt.

Two layers, one binding. A copy of the database, a backup or a dump holds ciphertext and wrapped keys only. Opening either needs a KMS call that names the right connection.

Who can unwrap a key

One workload identity in our platform is allowed to use the key-encryption key. It authenticates to Google Cloud through workload identity, so there is no key file to leak.
Every unwrap is a KMS call recorded in Cloud Audit Logs.
The key-encryption key rotates every 90 days. Older versions still decrypt what they protected; new values always use the current version.
The platform refuses to start in production without KMS. There is no fallback mode that stores secrets any other way, and older storage formats are not read.

Two credentials, two jobs

Most of what vCISO Lite does is read: it scans your platforms and checks the results against your policies and frameworks. That uses the read-only credential you connect, such as a read-only administrator or auditor role.

Changing anything uses a separate write identity that you create and scope. A read credential is never used to write. Applies to every platform with a separate write identity

The write identity holds only the permissions the fixes need. It is released only to the part of our platform that applies changes, only while write access is active, and never once the connection has been revoked.

Platform	Reads with	Writes with	Write identity
Okta	Read-only admin token	Your API Services app	Separate
AWS	Read-only role, no keys	Opt-in fixes role, no keys	Separate
Others	OAuth or API token	Same connection, gated	Moving

Okta

Changes run as an API Services app you create in your Okta org. Never a person's account, and never a personal API token.

We generate a key pair for your org. You add the public key to the app; the private key stays with us, encrypted as described in Part I.
The app signs in with a signed client assertion (private key JWT). There is no shared secret to copy or leak.
Its access tokens are bound to a separate, short-lived proof-of-possession key (DPoP), so an intercepted token is useless on its own. Tokens expire after one hour.
You grant the app only the scopes the fixes use (today, managing policies) and assign it a custom administrator role limited to Authentication policies.
Before write access is issued, we sign in as the app and confirm its role can read your Authentication policies.

We will never ask for Super Admin, Org Admin or Security Admin, for any feature. Okta · standing commitment

AWS

We store no AWS access keys.

Reading uses a read-only role you create in your account from our CloudFormation template.
Changes use a second, opt-in role from the same template. It can only turn on S3 Block Public Access for a bucket you approved.
Our platform reaches those roles through identity federation. Our cloud workload identity signs in to AWS without a stored secret and assumes your role, which trusts only our role and only with your connection's External ID.
Every session is temporary, and every role assumption appears in your CloudTrail.

Other platforms

Other platforms connect with OAuth or API tokens limited to the narrowest scopes they offer, stored the same way. Where we make changes on them, the same write access, approval and verification steps apply. We are moving each platform that supports it to its own separate write identity, as Okta and AWS have.

What each failure can and can't reach

A copy of our database or a backup is taken. It holds ciphertexts and wrapped keys only. Without KMS access, which no file or backup carries, they can't be decrypted.
A stored value is moved to another customer's record. It fails to decrypt, because each value is bound to its own connection.
An Okta access token is intercepted. It can't be used without the proof-of-possession key, and it expires within an hour.
Our running platform is compromised. An attacker could do no more on your systems than the roles you granted allow, which never include full administrator rights. Write access is time-limited, every key unwrap is logged, and you can revoke access at any time.
You stop trusting a connection. Revoke it. Its credentials are withheld at once, its write access ends, and nothing more is read or changed.

What stays in your hands

Revoke write access for a connection at any time. Pending changes go back to step-by-step guidance.
Revoke a connection, and its credentials stop being used immediately.
Replace the Okta app's key whenever you like. A new key stops the old one from working until the app is checked again.
Delete or disable the app or role in your own platform. That ends our access regardless of anything on our side.
See every request, approval, change and rollback in the connection's activity and in your audit trail.

The permissions you grant are the ceiling. Nothing on our side can raise it, and you can lower it or remove it without asking us.