Compliance and trust

A compliance review does not ask whether a platform feels secure. It asks how each control maps to the families it has to attest, and what the platform can put in front of a reviewer. This page is that map: it describes the controls the architecture actually implements and the family each one belongs to, so that when your review reaches a control family, the answer is a mechanism you can inspect rather than a description you have to accept. It is the index a reviewer reads first, with the detail behind each control on the pages it links to. A formal certification is a separate, external step that an auditor produces, and this page does not claim one; what it gives you is the set of controls a certification rests on.

The stance the controls rest on

The single decision that shapes every control here is that an agent is treated as untrusted code that does useful work, not as a trusted member of staff. A trusted-insider model hands the agent broad access and relies on it to behave, and the day it misbehaves, through a bad instruction, a prompt injection, or a plain mistake, the blast radius is everything it could touch. Disco Parrot starts from the other end. The agent is contained by a boundary it cannot reach past, handed credentials it cannot keep, gated by a person at the points that matter, and recorded at every step.

That stance is why the separation in this platform is architectural, not only logical. The container is the boundary, so the agent does not enforce its own permissions; the wall does. A standing key is never placed where the agent could read it, so there is nothing to harvest. The riskiest changes route back to a person, so an agent never applies them alone. A control family that other tools satisfy with a policy and a hope, this platform satisfies with a structure a reviewer can see.

The controls, mapped to the families a review checks

A review works through control families. Here is where each one lives in the platform, with the page that covers it in full.

The point of the table is the one a reviewer cares about: not one of these is a slide. Each row is a mechanism with a page behind it and code behind the page, so a control family that has to be attested is a control family you can examine.

What you can put in front of a reviewer

Mapping controls to families is only half of a review; the other half is evidence. The platform is built to produce it rather than describe it. Every meaningful change is on the audit trail with its actor and the person-or-agent mark, the slice a reviewer asks for exports to a scoped file, and the platform's boundary events carry a separate evidence record you can stream to your own security tooling and seal into a hash-verified package for a formal handoff. An approval is a recorded decision, a refused secret is a row with the secret shown by name and never by value, and a credential grant is on the record from request to expiry. So a review reads the record instead of trusting a description, which is the property that turns "we are careful" into something a reviewer can confirm. And the review is largely self-serve for the people who run it: a compliance owner or a billing manager pulls the audit export and reads the evidence through their own audit access, without ever holding access to the work itself, so the separation of duties holds even while the review is underway.

Where each assurance lives

Some assurances live alongside the architecture rather than inside it, and a clear review sources each from its right place. Certifications are attestations a third party issues after examining a control environment over time; this page maps controls to families, and a formal attestation is the separate external step that a certification process produces. Identity policy such as multi-factor authentication is enforced at your identity provider, where it belongs: sign-in runs through Microsoft Entra and Google, so the conditional-access and multi-factor rules your organization already runs apply to Disco Parrot the same as to everything else federated through them. And data-processing and availability terms, the contractual commitments about how data is handled, who processes it, and how the service is kept running, are confirmed with your account and legal teams as part of an agreement, which is where a commitment of that kind carries its weight. The sub-processors in the path, the cloud the platform runs on and the model provider you select for an agent, are named in that same agreement, where the list stays current. The architecture gives you the controls; attestation, identity policy, and contract are the complementary layers around them, and a review is cleanest when each is sourced from where it actually lives.

A vendor review, end to end

A CISO evaluating Disco Parrot brings the checklist every vendor review brings: access control, separation of duties, audit, encryption, change management. A year ago the answers would have been a security questionnaire and a hope. Here each line maps to a page and each page to a mechanism. Access control is named scopes and routes that declare their permission. Separation of duties is a billing manager who sees the audit log and none of the work. Audit is a trail with the agent's hand marked apart and an evidence record that streams to the CISO's own tooling. Encryption is managed-identity access and a per-workspace vault. Change management is a person gating the steps that ship. For the lines that live alongside the architecture, the attestation, the identity policy, the data-processing terms, the CISO knows exactly where to source each, because the page that maps the controls names which assurances live where. The review moves quickly because each line is a thing the platform can show rather than a thing it asks the reviewer to take on trust.

Why compliance and trust work this way

The tempting way to handle a compliance page is to claim the certifications a buyer wants to hear and let the questionnaire sort it out later. It is also the way to lose a serious review the moment a reviewer asks to see the control behind the claim. So this page does the opposite. It claims no certification, it maps each control to the family it belongs to, and it points at the mechanism and the code behind every one, because a control you can inspect is worth more in a real review than a badge you cannot substantiate. The trust the platform asks for is the kind you verify: the agent is untrusted code in a boundary it cannot cross, the controls are structures rather than promises, and the record is something you read rather than something you are told.

For the person who owns compliance, this is the map you start a review with. Each control family points to a mechanism with a page and code behind it, the evidence exports for a reviewer, and the assurances that live outside the architecture, certifications, identity policy, and data-processing terms, are named as external so you source each from where it belongs.

For the person who owns security, the value is that the separation is architectural. The container is the boundary, the standing keys are never placed where an agent could read them, and the riskiest changes route back to a person, so the controls hold by structure rather than by everyone remembering to do the careful thing.

For a prospect evaluating the platform, this is how you tell a platform built for a review from one that hopes to avoid one. Every control here is a mechanism you can examine, the page makes no claim it cannot substantiate, and the things that are external are named as external. The trust on offer is the kind you check.

For a team lead, the practical version is that adopting agents does not open a compliance project for each one. The controls are platform-wide, so a new agent inherits the boundary, the leases, the checkpoints, and the record rather than re-earning them.