Security, compliance & engagement posture
Written for the people who have to sign off on us: security reviewers, procurement, and the engineering manager who will actually grant the access. It describes how we work inside your controls — and, just as importantly, what we do not claim.
What we claim, and what we do not
A lot of vendor security pages imply certifications they do not hold by listing framework logos next to the word “aligned”. We would rather be plainly useful.
What this page is: a description of how Cloudadorn engineers work when embedded in a client environment, and the controls we design into the systems we build. These are practices we hold ourselves to and that you can hold us to contractually.
What this page is not: an attestation. Where a formal certification, audit report, insurance certificate or executed agreement is required for your review, it has to come from a document, not a web page — see requesting documents below.
For reviewers using a questionnaire: send it. We will complete it against our actual practice and mark anything we cannot evidence as “not held” rather than “in progress”. That answer is usually more useful to you than a maybe.
Access model
Forward Deployed Engineering means our people work inside your environment, so the access model is the single most important control in the engagement. Our default position:
- Your identity provider, your accounts. We work under named accounts issued by you and governed by your joiner–mover–leaver process. We do not ask for shared credentials, and we will decline them if offered.
- Least privilege, scoped to the charter. Access is requested against the specific systems in the delivery charter. If the work does not need production data, we do not ask for production data.
- Your devices or ours, your choice. Where your policy requires managed endpoints or a virtual desktop, we work that way. Where it does not, our engineers work on full-disk-encrypted machines with screen lock and current OS patching.
- Offboarding is part of the exit. Access revocation is a line item on the handover checklist, not something you have to remember to chase.
- We will not ask you to skip a step. Onboarding is measured in days rather than weeks because access requests are the first thing we start, not because anyone waives a control for us.
Handling your data
- Data stays in your environment. The default is that customer data is processed in your cloud tenancy and your warehouse. Where a piece of work genuinely requires an extract to leave, that is agreed in writing first, scoped, and time-bound.
- Production data is not a development convenience. We work against masked, synthetic or subset data wherever the task allows it.
- Secrets do not live in code, tickets, prompts or chat. They live in your secret manager. This is a review point in every pull request we raise.
- Sensitive categories get named handling. Where an engagement touches personal data, health data or payment data, the applicable agreement — a data processing agreement, a business associate agreement, or both — is executed before access is granted, not after the first sprint.
Secure development practice
These are the practices we bring to a codebase, and the ones we will follow in yours unless your own standard is stricter, in which case we follow yours.
- All changes by pull request, reviewed by someone other than the author.
- Infrastructure as code, with the desired state in version control and promotion between environments by merge rather than by console.
- Dependency and secret scanning in CI; a failing scan blocks the merge.
- Least-privilege service accounts and short-lived credentials in pipelines.
- Structured logging that records who did what, without recording the payload that made it sensitive.
- Rollback by revert. If undoing a change requires a runbook and a war room, the deployment model is the defect.
AI-specific controls
Agents are the part of our work that most often triggers a security review, and reasonably so — an agent is software with credentials. The controls we build in are the same ones described throughout the use-case patterns:
- Tool-scoped action, not open access
- An agent reaches your systems only through a narrow, enumerated set of tools with their own permissions. It can update an invoice status; it cannot rewrite the vendor master.
- Human gates on consequential actions
- Anything that moves money, contacts a customer, or deletes in bulk stops at a named approver. The agent prepares the decision; a person makes it.
- Idempotent writes
- A retry after a timeout cannot produce a second payment. This is a design requirement, not a monitoring problem.
- Refusal before generation
- Where a model generates queries, the governed semantic layer decides what is reachable before the model is asked — so unmasked personal data and cross-tenant joins are not in scope to begin with.
- Evaluation as a release gate
- A change to prompts, tools or thresholds must clear a golden set that includes hostile inputs and prompt-injection attempts before it can be promoted.
- Auditability
- Prompt, generated action, approver and outcome are logged so a decision can be replayed for an auditor without reconstruction.
- Model and data boundaries
- Which model provider is used, where it is hosted, and whether any data may be retained by it are engagement decisions made with you and written down — not defaults we pick for you.
This website
The site you are reading is a static site with no login, no database and no user accounts. It is deliberately boring:
- No third-party scripts, tag managers, or analytics providers are loaded. There is an internal event layer in the page code, but it is inert until a provider is configured, and no provider is configured today.
- Web fonts are self-hosted, so loading a page contacts no other domain.
- No cookies are set by this site.
- The only outbound request the site can make is the contact-form submission you explicitly trigger.
Full detail is in the privacy notice.
Found a vulnerability in this site? Email info@cloudadorn.com with “security” in the subject line and we will acknowledge it. We do not currently run a paid bounty programme.
Engagement & commercial model
| Shape | What it is | When it fits |
|---|---|---|
| Audit | A scoped assessment of architecture, data and bottlenecks, ending in a written recommendation you own. | You know something is stuck but not precisely what. Usually the first thing we do. |
| FDE pod | Senior engineers embedded in your squad against a written delivery charter, committing to your repository. | You have the direction and need the delivery capacity and the hard-path ownership. |
| Scoped delivery | A defined piece of work — a migration, a platform, an agent — with agreed acceptance criteria. | The outcome is well understood and you want it owned end to end. |
Every shape ends the same way: documented systems, a handover, and revoked access. If we are still indispensable a year after go-live, we did the engagement badly.
Requesting documents
The following are the items a security or procurement review usually needs. They are not published here, because a document that matters should be sent under an appropriate agreement and dated — not scraped off a marketing page.
- Certificate of insurance
- Data processing agreement (and business associate agreement where applicable)
- Mutual non-disclosure agreement
- Completed security questionnaire (yours, or a standard one)
- Current certification or attestation status, stated plainly
- Named security contact for the engagement
To request any of these: email info@cloudadorn.com or use the contact form and select “Security or vendor review”. Tell us your deadline — reviews have dates, and we would rather work to yours than discover it late.
If you are evaluating us alongside other firms, the fastest way to compare is to send us your questionnaire and see which answers come back qualified.
Start a vendor review