Bring This to Your Team
If you already understand this model and just need your manager, CTO, or security lead to sign off, this page is built to be forwarded. It's the short version, with links to the deep version for whoever wants it.
Draft an email to your management
Don't want to write this from scratch? Here's a starting draft, addressed from you to your own management, about working with continuous.engineering generally, with the security model front and center. It's written to stand on its own for someone seeing this for the first time: a clear ask up front, who continuous.engineering is, the security specifics, and a direct call to action at the end. Click below to open it in your mail client with the subject and body already filled in; you just add the recipient, your name, and the specific need in the two remaining bracketed spots.
Open draft in your mail client
If that link doesn't open cleanly in your setup (some webmail clients handle blank-recipient mailto: links inconsistently, and the body is long enough that a few older desktop clients may truncate it), here's the same text to copy directly:
Show the draft as plain text
Subject: Proposal: bringing in continuous.engineering (security overview included)
Hi [Manager],
I'd like your OK to bring in continuous.engineering for [architecture / security review / AI systems work - fill in the specific need]. Before you ask (I know you will), here's exactly who they are, what access they'd need, and how we stay in control of it the whole time.
Who they are: continuous.engineering is founded by Shree Mandadi, who works with an extremely talented team of engineers covering the full lifecycle, from infrastructure architecture through build, ongoing support, and audits, including real third-party auditors, not just self-attestation. Their focus areas include architecture, agentic AI, and regulated infrastructure like healthcare and payments.
More detail: https://continuous.engineering
LinkedIn: https://linkedin.com/in/ShreeMandadi
On security specifically, here's what matters most:
- We never hand over credentials of any kind. No passwords, no access keys, no VPN accounts, ever.
- Their engineers authenticate through their own MFA-enforced identity provider, and we are the ones who grant them a scoped, time-limited role directly inside our own environment. We control the grant, not them.
- Every action they take is logged in our own audit trail, under the individual engineer's identity, so we can always see exactly what happened and when.
- We can revoke their access with a single command at any time, and nothing is left behind afterward.
- Their entire access model is public and auditable: https://grant-access.continuous.engineering
I've also checked how this maps to our own compliance obligations (SOC 2, ISO 27001, HIPAA, PCI DSS), and it actually strengthens our audit position rather than weakening it: https://grant-access.continuous.engineering/compliance
Bottom line: this is less risk than some vendors we already work with, not more.
Can I get your OK to move forward? Happy to walk through any of this live first if you'd rather.
[Your name]The 90-second version
continuous.engineering never receives credentials. Our engineers authenticate with MFA against our own identity provider, and that identity is granted a time-boxed, least-privilege role directly in your cloud account: nothing shared, nothing standing beyond what's needed, nothing left behind when the engagement ends. Every action we take is logged under the individual engineer's identity, in your own account, visible to you in real time. You deploy it, you own it, you can revoke it with one command.
That's the whole model. Everything else on this site is detail in support of that sentence.
What your security team will ask, answered
"Are we handing over a password or an access key?" No. Nothing is ever typed into our systems and nothing is ever emailed, Slacked, or stored on our side that could leak. Access is granted by you, in your account, to our identity provider; we never hold a credential of yours at all.
"What happens if continuous.engineering is compromised?" An attacker who compromised our systems would need to also compromise our own MFA-enforced SSO to do anything, and even then would only reach whichever role tier that specific engineer's identity was scoped to, not a master key to every client. Every session is short-lived (AWS/GCP: 2-4 hours) or individually revocable (Azure), so there's no long-lived credential to steal in the first place.
"Can we see exactly what they did, after the fact?" Yes: every action appears in your own cloud's audit log (CloudTrail, Cloud Audit Logs, or Activity Log) under the individual engineer's identity, not a shared account. On AWS this comes with a dashboard out of the box. See Monitoring.
"How fast can we cut access if something goes wrong?" One command, immediate: delete a CloudFormation stack (AWS), or run the provided removal script (GCP/Azure). No key rotation, no hunting down who has what: there was never anything standing to begin with. See Revoking access.
"Does this meet our compliance obligations?" It maps directly to SOC 2 CC6/CC7/CC9, ISO 27001 A.5/A.8, HIPAA 164.312, and PCI DSS Requirements 7/8/10, with a ready-made evidence package for your auditor. See Compliance.
"What can they NOT do?" Whatever isn't explicitly granted. Roles are scoped per task (read-only, operations, data, admin), production can be walled off entirely with one attachable policy (CE-DenyProd, on AWS/GCP today), and database-tagged instances are the only ones reachable for data work. Full breakdown: Role Reference.
"Is this a bigger lift for us than just giving them a login?" No: for AWS and GCP it's one script/one click, run once, and access just works from then on. Azure is one script too. None of these require ongoing maintenance on your side.
The one-sentence version, if you only get one sentence
"They get a scoped, time-limited role with a full audit trail, and we can revoke it instantly; it's actually less risk than the shared credentials we've used with other vendors."
For whoever needs to see receipts
| They want to know... | Send them to... |
|---|---|
| The full trust and revocation model | Security Model |
| Exact framework-by-framework compliance mapping | Compliance |
| What each role can and can't do | Role Reference |
| Why this beats the alternatives (shared keys, VPN+SSH) | Why This Model |
| The actual deploy steps, once approved | AWS · GCP · Azure |
Still need a live conversation? devops@continuous.engineering, but most teams don't need one to get to yes.