A security tool has to answer this page honestly.
Cloud Patrol asks for access to the configuration that defines your network perimeter. That deserves specifics rather than reassurance, including where the work is not finished.
Permissions
Cloud Patrol authenticates as its own principal and assumes a role you create in each target account. It never stores account keys, and it never asks for a long-lived credential belonging to a person.
The default grant is read-only: the permissions needed to describe security groups, network ACLs, VPCs, route tables and gateways. Nothing in the read path can modify configuration.
- AssumeRole
- External ID
- No stored account keys
Read-only and write access
Write access is a separate, explicit grant that you can decline entirely. Cloud Patrol is fully useful without it: findings, traffic testing and impact analysis all work on read-only collection.
When write access is granted, a change is still never applied silently. Cloud Patrol produces the Terraform or CLI for the change, states its impact, and waits for an approval recorded against a named user.
- Opt-in
- Approval required
- Generated, not hidden
Credential handling
Connector credentials are encrypted at rest with a key held outside the database. No credential is written to a log, returned by the API, or rendered in the console, in plaintext or otherwise.
The platform is built so that a database dump alone does not yield a usable credential.
- Encrypted at rest
- Never in logs
- Never in API responses
Encryption
Traffic to the platform is TLS only. Data at rest is encrypted at the volume level, and connector secrets are encrypted again at the field level with a separate key.
- TLS in transit
- Encrypted volumes
- Field-level for secrets
Tenant isolation
Isolation is enforced in the data-access layer, not in the interface. Every query in the application is issued through a repository bound to one organization at construction time; there is no way to build an unscoped query.
This matters because an endpoint that forgets a filter is a breach, and interface-level filtering is exactly the kind of thing that gets forgotten.
- Enforced at query level
- Not a UI filter
- Covered by tests
Audit logging
Every change records who made it, when, the previous value and the new one. Changes made outside Cloud Patrol appear in the same timeline, so configuration drift is visible rather than inferred later.
Collection is append-only: a new snapshot never overwrites its predecessor, so the state at a past date can be produced rather than reconstructed.
- Immutable snapshots
- Outside changes tracked
- Previous values kept
SSO and RBAC
SAML and OIDC single sign-on, with roles scoped so that reading findings, approving a change and administering the organization are separable permissions.
This is in active development and is the next stage of work. Until it ships, treat any deployment as an internal, trusted-network tool.
- SAML
- OIDC
- In development
Where we actually are.
Cloud Patrol is pre-certification. SOC 2 Type II is the current objective and the controls are being built toward it, but no audit has been completed and we are not going to imply otherwise with a badge. If you need a completed report before you can evaluate a tool, tell us and we will be straight with you about timing.
What exists today: tenant isolation enforced in the data layer and covered by tests, encrypted credential storage, append-only audit history, and read-only collection by default.
If you find a security issue in Cloud Patrol, we want to hear about it before anyone else does. Use the contact form and mark it as a security report; it will be routed directly rather than through sales.
Ask us the hard questions first.
A demo can run entirely read-only against a single account, so you can evaluate the tool without widening any access.