For security architects and reviewing engineers
This page draws the boundaries, says where a compromise stops, lists what credentials are held and which are deliberately never held, and marks each property as designed or independently attested rather than blending the two. An architecture nobody can criticise is one nobody described.
A design review is an exercise in reading for absence. The document arrives polished, the diagram is clean, and the interesting information is entirely in what the diagram does not draw — the management plane that reaches every box, the shared cache nobody labelled, the internal call that crosses a boundary the picture implies is solid.
Vendors have learned the vocabulary without learning the discipline. Encryption at rest appears on every page and answers almost nothing, because the interesting question is who holds the key material and which processes can ask for a decryption. Least privilege appears on every page too, and rarely survives the follow-up question of who granted the last exception and whether it was ever taken back.
What actually determines the damage is reach. A compromised component matters in proportion to what it can call, what credential it carries, and how far a stolen token travels before something refuses it. That is a structural property of a design, it is decidable from a diagram, and it is exactly what a marketing document is written to avoid discussing.
The supply chain has become most of the surface. Direct dependencies are reviewed and transitive ones are not, build machinery is more privileged than anything it builds, and the artefact that reaches a runtime is rarely the artefact anybody inspected. A reviewer who only reads application design has reviewed a minority of the attack surface.
And then there is the gap between a design and its operation. The architecture may be sound and the exception granted at two in the morning during an outage may still be live eighteen months later, because nothing was built to expire it. Reviewers know this, which is why the credible question is never "is it designed well" but "what makes the design stay true".
A reviewer cannot bound the damage of a compromise without knowing what each component may call and what credential it carries — and almost no vendor document states either, so the reviewer is asked to accept a posture in place of a boundary.
The architecture here is organised around that question rather than around a feature list. Each running component has a declared reach: the services it may call, the storage it may touch, and the credentials it may present. A component that has no reason to reach something cannot reach it, and that is a deployment property rather than a policy sentence.
Credentials for anything belonging to the customer are the sharpest version of this. The design intent across the whole platform is that connections to a customer estate use credentials the customer issues, holds and can revoke without asking anybody, and the master key material that protects them is held separately from the records it protects. The consequence worth stating plainly is that revocation is unilateral: you do not file a request to end our access, you end it.
Between customers the boundary is enforced at the query layer rather than trusted to application discipline, and that distinction has its own page because it is the one reviewers press hardest. What belongs here is the reason: application-level filtering fails silently the first time somebody writes a query that forgot the clause, and a boundary that fails silently is not a boundary.
On the supply chain, the honest position is that this is the least mature part of any architecture including this one. What exists is a dependency inventory, a build that produces a recorded artefact rather than an unrecorded one, and a stated refusal to add a dependency casually. What does not exist is an independent attestation that any of that held, and this page will not describe a designed property as an attested one.
A stated blast radius for each component — measured by whether the review can name what a compromised component may call, without asking a human.
Unilateral revocation of every connection into your estate — measured by revoking one credential on your side and confirming the connection stops without a support request.
Tenant separation enforced below application code — measured by whether a query missing its tenant clause fails rather than returning a neighbour’s row.
Expiry on privileged exceptions — measured by asking for the list of live exceptions and their expiry dates, and finding none without one.
A recorded build artefact — measured by whether the running version can be traced to the inputs that produced it.
Change visibility before effect — measured by whether a change appears in your record before it reaches your environment.
no independent penetration test report exists to hand over today, no security certification is held or claimed, and the supply-chain properties above are designed rather than attested. An independent SOC 2 Type II attestation is in progress and no report exists yet. Where this page says designed, it means designed, and a reviewer should treat it as a statement of intent that has not been tested by a third party.
The design assumes your controls rather than replacing them. Authentication belongs to your identity provider, secrets belong in your secret store, log events belong in your stream, and the network position belongs to whoever owns the network. A vendor asking to be an exception to any of those has told a reviewer where to look.
Nothing here requires an inbound hole. Where a connection is needed into a customer estate, the direction and the credential are described before anything is deployed, and a design that would need an unrestricted inbound path is treated as a design failure rather than a documented requirement.
Where a control is yours and where it is ours is written down as a matrix rather than left implied. A control marked shared with no split written out is an unassigned control wearing a reassuring word, and that is the specific document defect that survives most reviews.
The two words are not interchangeable and this page keeps them apart deliberately. Designed means the property is built into how the system works and can be described and demonstrated. Attested means an independent party examined it and produced a report. Almost everything on this page is the first, and a document that blurs them is doing the reader an unkindness disguised as confidence.
On independent assurance, the accurate statement is that a SOC 2 Type II attestation is in progress and no report exists yet, so nobody can be handed one. When it exists it will be described as what it is — an attestation with a defined scope and period — and not as a certification, because those are different instruments and the second word is routinely used to imply the first.
We hold neither a FedRAMP authorization nor a FedRAMP certification, at any impact level, and claim no equivalency. That is stated here rather than left to be discovered, because a security architect frequently reviews on behalf of a programme where it matters.
The most useful thing a reviewer can do with this page is test a property rather than believe it. Revoke a credential and watch the connection stop. Ask for the live exception list. Ask what a compromised component may reach. Each of those has a checkable answer, and a vendor who cannot produce one has answered the question anyway.
The document worth asking for first is the responsibility matrix, because it is the one that reveals whether anybody has thought about the boundary at all. Ask for it before a demonstration. A matrix with unassigned controls is a finding on its own and it takes ten minutes to read.
Refuse a summary where a detail is available. If a section of your review would have to say "as described by the vendor", that section is not finished, and the correct response is to ask for the underlying description rather than to accept the summary and note a residual risk.
Treat a request for exemption as evidence. A vendor who does not want your scanner reaching them, your logging receiving their events, or your identity provider governing their accounts has given you a finding without you having to look for it. Nothing here asks for any of those exemptions.
And weigh the designed-versus-attested split honestly in your own risk register. A design intent that has never been independently examined is a real position and it is a weaker one than an attested control. Recording it as designed is not a formality; it is the accurate entry.
A written architecture review against your own control framework, covering one intended deployment shape, before anything is installed anywhere.
A demonstration answers a question a security architect did not ask. The first artefact worth exchanging is the boundary description and the responsibility matrix, because they are what determine whether a longer conversation is worth anybody’s time.
If that review produces findings, they belong in the record before a pilot rather than after one. A finding raised during a review costs a conversation; the same finding raised during an assessment costs a programme.
Where a bounded pilot follows, the observation phase this architecture recommends everywhere requires read-only access — which is the smallest thing a security reviewer can be asked to approve, and the correct place to start.
You should not believe it — you should test three things from it, and each takes under an hour. Revoke a credential on your side and confirm the connection stops without anybody contacting us. Ask for the live privileged-exception list and check every entry has an expiry. Ask what a single compromised component may reach, and see whether the answer arrives as a map or as a paragraph. A vendor who cannot produce those has answered your question regardless of what their page said.
No independent penetration test report exists to hand over today. That is stated here rather than deflected, because you would find out during the review and the discovery would be worse than the fact. What does exist is a description precise enough that your own team could scope a test against it, and no objection from us to your team performing one — a vendor resisting your assessment has told you where the weakness is.
Declared reach. A component receives, at deployment, the list of services it may call and the credentials it may present, and it cannot acquire more at runtime by asking. So the damage from a compromised component is bounded by that declaration rather than by whatever the network happens to permit. That is a structural property you can read from the deployment rather than a control you have to trust somebody to be operating correctly, and it is the specific question this page is organised around.
It is, and that is deliberate rather than accidental. A dependency inventory and a recorded build are real and they are not an attestation, and the reviewers who press hardest here are right to. Marking that section as designed rather than attested is the accurate entry for your risk register, and inflating it would buy a signature at the cost of the one thing that makes the rest of this page worth reading.
Then the resistance is the finding, and there is none here. Nothing in this architecture asks to be exempt from your scanning, excluded from your logging, or governed by accounts your identity provider does not control. The design assumes your controls rather than substituting for them, which means your team forms its own view instead of reading ours.