Security
What we store, what we never touch
A credential is a liability the moment it leaves your console. This page describes exactly what we hold, how it is sealed, and how it stops.
What we store
- A masked hint so you can recognise the credential in a list
- A fingerprint, used only to reject duplicates
- The provider fields you submit, sealed with AES-256-GCM
- The consent text you accepted, and every status change with a timestamp
What we never store
- A plaintext credential after sealing
- Your provider password, MFA seed, or recovery codes
- Your provider billing console or payment method
Envelope encryption, rotated by version
Each credential gets its own data key, wrapped by a key-encryption key held in the deployment environment rather than in the database. Every row records which key version sealed it, so rotation does not require re-entering credentials.
Least-privilege paths, per provider
These are the access paths we ask for. If you cannot use one of them, tell us — do not send a stronger credential than the job needs.
| Provider | Access we ask for | Never required |
|---|---|---|
| Anthropic | A workspace-scoped API key, or an organization Admin API key restricted to usage and cost reports. | Organization owner login, password, or MFA device. |
| AWS Bedrock | A cross-account IAM role with an external ID, granting bedrock:InvokeModel and nothing else. | Root account credentials or a long-lived access key for an administrator. |
| Azure OpenAI | An Entra ID application assigned the Cognitive Services OpenAI User role on one resource. | Subscription owner access, or an account key that can read and regenerate secrets. |
Lifecycle and audit
A credential moves through verifying, active, paused, rejected, revoked, expired, or duplicate. Every transition is written to an event log with the actor, so a stop is provable rather than promised.
Retention and deletion
Credentials are kept while the account is open. Deleting a credential or the account destroys its ciphertext; settlement records are retained because they are the accounting evidence behind money already paid.
Incident response
Report a suspected exposure to support@apicash.ai. We revoke affected credentials, notify impacted accounts, and publish the timeline on the status page. Never send a full key in the report.
Internal access control
Staff roles are separate from user accounts, and the admin console requires a TOTP code on every session. Each privileged action writes an audit entry with the actor, the entity, the before and after state, and a hashed IP. Credential ciphertext is unwrapped only server-side, by a key-encryption key supplied by the deployment environment.
What we do not claim
We hold no SOC 2 or ISO 27001 attestation, no HSM, and no third-party penetration test report we can share yet. The key-encryption key lives in the deployment environment, so the platform operator sits inside the trust boundary. We would rather state that than imply a certification we do not have.
What we will never ask for
- Your provider password or one-time codes
- MFA seeds or recovery codes
- Ownership transfer of your account
- Remote access to your machine or console
- Root or account-owner credentials of any kind