Security & Governance
Built for governance. Designed for security.
Hyvop works inside your existing boundaries. No new attack surface. Self-hosted, or single-tenant managed in your region.
Pre-launch. This is our security model and roadmap; SOC 2 is in progress, not complete.
Separation of duties
The agent never acts alone.
| Role | Responsibility | Can execute? |
|---|---|---|
| Owner | Decides the action (delete, resize, keep) | No |
| Manager | Approves or rejects the Owner's decision | No |
| Hyvop Agent | Executes the approved action via cloud API | Yes, only after approval |
Every decision is logged with who approved, when, from which IP, and why.
Boundaries
What we never do
| We never | Instead, we |
|---|---|
| Read data inside your databases, storage, or workloads | Process resource metadata, tags, and cost figures only |
| Store long-term cloud credentials | Use scoped, least-privilege IAM roles you create and control |
| Act autonomously on destructive changes | Require explicit confirmation and approval |
| Co-mingle your data with other customers | Run isolated, single-tenant processing |
| Retain your data indefinitely | Give you full control of retention |
Data handling & privacy
Your data stays yours.
What data do you access? Resource metadata, tags and cost figures. Nothing inside your resources.
Do you read workload or customer data? Never.
Where is data processed? In your self-hosted deployment, or a single-tenant Hyvop Cloud instance in your region.
How long is data retained? You control retention entirely.
What about the LLM assistant and NLP dashboards? The LLM runs on your own keys inside your deployment. Nothing is exported.
Authentication & access (planned)
No new user database.
Hyvop plugs into your identity provider. Role-based access, no new user database.
| Identity provider | Status |
|---|---|
| Okta (SCIM + SAML) | Planned for launch |
| Microsoft Entra ID (Azure AD) | Planned for launch |
| Google Workspace | On the roadmap |
Least privilege
Cloud integrations by design
| Cloud | Integration method | Permission scope |
|---|---|---|
| AWS (first) | IAM Role (cross-account) | Read-only metadata and cost; write limited to specific remediation actions |
| Azure (roadmap) | Service Principal with custom role | Read-only Resource Graph and Cost Management; write scoped to resource groups |
| GCP (roadmap) | Service Account with predefined roles | Read-only Asset Inventory and Billing; write scoped to specific projects |
| VMware / OpenShift (roadmap) | API token with read-only scopes | Inventory and performance metrics; write via controlled workflows |
Audit-ready by default
Every remediation leaves a trail.
- • Who initiated the detection
- • Who was identified as Owner, Manager, and Operator
- • The exact conversation and approval
- • Who approved, when, and from which IP
- • The cloud API call and its result
- • Full before/after state
Exportable to your SIEM or audit tools.
Security architecture
Foundations, not afterthoughts.
- • All data encrypted in transit (TLS 1.3) and at rest (AES-256)
- • Single-tenant, isolated processing, you host it
- • Third-party penetration testing planned ahead of general availability
- • SOC 2 Type II program planned
- • GDPR-aligned data handling