Read operations
Supported discovery adapters read provider inventory and selected metadata. They do not invoke agents, deploy resources, or change provider configuration.
SECURITY & TRUST
Your keys deserve
a clear answer.
Read-only discovery. Encrypted credentials. Clear control.
Connecting a source means trusting CatProof with a credential. Here is how the hosted application stores it, uses it, and keeps it separate from the inventory your team sees.
Encrypted storage
Saved credential values use authenticated encryption in a separate PostgreSQL table. The encryption key is held separately in service configuration.
Owner control
Only a registry owner can save, replace, or remove credentials. Saved values are not returned through the application’s credential API.
THE CREDENTIAL PATH
From your browser
to the source.
The diagram separates encrypted credential storage, in-memory use, and the inventory that users can view or export.
On small screens, scroll the diagram horizontally or read the steps below.
Hosted application: Render · Persistent application storage: PostgreSQLDownload architecture SVG ↓
- Submit over HTTPS.
The hosted application checks the signed-in session, request origin, registry membership, owner role, and target connection before saving.
- Encrypt and bind.
Fernet authenticated encryption protects the saved credential payload. The payload includes its registry and connection; those bindings are checked when it is loaded.
- Use in server memory.
An authorized provider read loads the credential server-side. CatProof must decrypt it in memory to authenticate the request to that provider.
- Keep the result separate.
Inventory, CSV exports, registry snapshots, and audit details omit saved credential values. Source metadata and local ownership decisions remain distinct.
What this boundary means
This is server-side encryption, not zero-knowledge storage. Operators with both database access and the service encryption key can decrypt saved credentials. The current design does not use a managed HSM/KMS vault for connector secrets.
TWO LAYERS OF CONTROL
Read-only behavior.
Least-privilege credentials.
CatProof’s behavior and your provider’s permissions work together. Both matter when deciding what access to grant.
What CatProof does
Supported connectors perform discovery and enrichment reads. Some provider APIs use POST to submit a search or metadata query; the operation’s purpose determines whether it is a read.
Recording an owner, review, or lifecycle decision changes the CatProof record. It does not change the source agent or stop its execution.
What your credential allows
Choose a dedicated credential with the minimum read permissions for the intended account, workspace, project, or resource scope.
A broadly privileged API key remains broadly privileged. CatProof’s read-only behavior does not reduce that key’s permissions at the provider. Some providers do not offer granular read-only keys; review their limitations before connecting.
Scope is connector-specific. One connection does not establish complete organization-wide discovery. Review each connector’s coverage and authentication requirements →
ACCESS & REQUEST BOUNDARIES
A key stays tied
to its connection.
Registry and connection checks
Credential operations use the authenticated registry, validate the connection belongs to it, and recheck the owner role. Inventory uses tenant-scoped keys and PostgreSQL row-level security.
Protected provider requests
The hosted request policy requires public HTTPS destinations on port 443. Shared connector transport rejects redirects and cross-origin pagination before forwarding credentials.
Clear browser handling
Credential fields are masked, are not saved in browser storage by CatProof, and are cleared after submission, closing the dialog, or hiding the tab. Stored values are not shown again.
Separate evidence and secrets
Credential changes record an audit event without including the credential value. Shared connector errors use sanitized messages rather than echoing provider response bodies.
These are application safeguards, not a claim that an administrator or a compromised application cannot access data. Connect only to provider endpoints you are authorized to use.
YOUR CONTROL
Replace it.
Pause it. Revoke it.
Replace or remove in CatProof
- Sign in as a registry owner and open the saved connection.
- Choose Update credentials to replace the complete credential set.
- Choose Remove saved credentials & pause connection to clear the active saved credential and pause discovery.
Removal blocks fallback to older operator-configured credentials for that connection. Previously imported inventory and history remain; removal is not an immediate erasure guarantee for historical backups.
Revoke at the provider
To invalidate a key everywhere, revoke it in the source provider’s console. Removing it from CatProof does not revoke the provider-issued key.
Prefer dedicated, limited credentials. Use short-lived credentials where supported. Expired tokens currently need to be replaced in CatProof; automatic renewal is not generally available.
Connection and credential setup →QUESTIONS BEFORE YOU CONNECT
Details you can
make a decision on.
Can teammates retrieve my saved key?
The application does not return saved values through its credential API, inventory, or exports. Only registry owners can save, replace, or remove credentials. Authorized team members may use inventory features and trigger reads according to their role; that is different from retrieving the saved key.
Is CatProof certified or independently audited?
This page documents the implemented application safeguards. It is not evidence of a completed independent security audit or a CatProof compliance certification. A hosting provider’s certifications do not automatically certify CatProof. Contact us about your requirements before providing access.
Which encryption does the application use?
Saved connector credentials use Fernet authenticated encryption from the Python cryptography library. The service encryption key is stored separately in service configuration. This is a service-managed key, not a customer-managed key or a per-registry vault. Read the Fernet documentation ↗
Can I evaluate CatProof without a production key?
Yes. The interactive demo uses fictional data and makes no provider calls. You can also review the self-hosted Community Edition and its setup requirements. Hosted and self-hosted operating responsibilities differ.
Where can I ask a security question?
Email info@catproof.ai with your requirements or a description of the issue. Do not include API keys, tokens, passwords, or customer data in an email or chat message. Read the Privacy Policy →
Application architecture reviewed . This explanation reflects a code and documentation review; it is not an independent assessment of production infrastructure, operational access, or backup retention.
Start with a clear scope.
Review the source, its permissions, and the evidence you need.