Security
A summary of how ManageAI handles data, for IT and security reviewers. For the full security document and answers to your own questionnaire, please contact us.
Architecture: not in your request path
ManageAI installs no resident software in your environment. It works by reading each AI provider’s management APIs from our side with read-only permissions. Because we do not sit between you and your AI providers, your AI usage itself is unaffected even if our service stops.
Scope of data collected
| What we collect | What we never collect |
|---|---|
| Usage metadata (token counts, request counts, model names, API key identifiers, timestamps), cost data, organization metadata registered with the provider (project names, key names, key owners’ email addresses), and department and user names you register | The text of prompts (input) and generated results (output). We never collect, store or transmit it |
Not handling the text is a structural constraint, not an operational promise. We read only each provider’s usage statistics APIs, which return aggregated values. There is no code path in the service that handles the text, and no database column for it.
Credentials we hold
All credentials are read-only (OpenAI / Claude: read-only Admin API keys; Azure OpenAI: a service principal with a reader role only; AWS Bedrock: an IAM access key limited to viewing statistics; Google Vertex AI: a service account key with viewer permissions only). We do not request any permission to operate or modify your AI resources.
- Stored with envelope encryption (AES-256-GCM) and decrypted only while collection jobs run
- Only the last four characters are shown on screen. There is no function to display the full value again (our staff cannot view it either)
- The master key is kept in AWS Secrets Manager and is not included in source code
- You can revoke credentials at any time from each provider’s console, at which point our access stops
- Administrative operations, including registering and deleting credentials, are recorded in audit logs
Tenant isolation and authentication
- Every table carries a company identifier, and PostgreSQL row-level security (RLS) makes the database itself deny access to other companies’ data
- Invitation-only accounts, TOTP multi-factor authentication, two roles (admin / viewer), and tamper-proof audit logs
- In an internal audit in July 2026, we ran live access tests while unauthenticated and with other tenants’ identifiers, and confirmed that no data could be retrieved
Infrastructure and data location
- Runs on AWS in the Tokyo region. Both the database and the processing environment are located in Japan
- The database sits in a private network unreachable from the internet, with storage encryption and TLS with server certificate verification
- Production and staging are fully separated: database, authentication, secrets and execution permissions
- Point-in-time recovery from automated backups (7 days)
Data retention and deletion
Data is retained while you use the service, and all aggregated data can be exported as CSV. On cancellation, we delete the credentials and collected data we hold (complete removal from backups occurs after the retention period).
Current limitations (full disclosure)
For your review, we disclose that the following are not currently supported. If any of these are mandatory requirements, please contact us to discuss feasibility and timing.
- No third-party certifications (such as ISMS / SOC 2)
- No SLA (uptime guarantee) is currently offered
- SSO (SAML / OIDC) and IP address restrictions are not supported
- Automated data retention management (automatic deletion / archiving) is not implemented
- No third-party penetration test or backup restoration drill has been conducted (an internal audit was conducted in July 2026)
To request the full security document or answers to your questionnaire, please contact us.