Loading
Preparing this Costframe view
Preparing this Costframe view
SECURE BY DESIGN
Read-only
by construction.
Costframe cannot modify your cloud resources, delete infrastructure, or read application data. The Azure, AWS, and GCP clients are built read-only, so the boundary is structural, not a policy promise.
Read-only trust boundary
Provider data enters Costframe. Provider writes do not.
01
Provider APIs
Read APIs, billing exports, inventory, metrics
02
Costframe normalizer
Org-scoped records, evidence freshness, detector inputs
03
Evidence Ledger
Checked signals, missing signals, confidence, price math
04
Review boundary
Tickets, reports, and guidance leave Costframe for human approval
Blocked boundary: Costframe does not import provider write clients for customer tenant operations and does not execute cloud changes.
Evidence Ledger
A finding shows the proof and the doubt.
finding · vm_resizereviewable
Evidence checked
CPU history, cost line item, resource state, SKU catalog reference
Evidence unavailable
Missing metric windows, unsupported provider fields, stale billing exports
Decision state
Confidence, contradiction checks, owner, approval status, verification plan
- 01Conceptual diagrams are labeled as diagrams, not dashboards.
- 02Illustrative examples can explain math or workflow, but they cannot replace product proof.
- 03Every savings figure shown publicly stays illustrative until it is verified against your own audit.
Interactive architecture diagrams
Inspect the system boundary from provider API to verified report.
Hover, focus, or tap a diagram. Motion is restrained and respects reduced-motion settings.
Read APIs feed evidence. Write APIs stay outside Costframe.
Billing, inventory, metrics, and recommendation APIs are used only where configured and permitted.
- 01Provider APIs
- 02Read-only client
- 03Org-scoped store
- 04Evidence Ledger
01 · VISUAL SECURITY MODEL
The trust model in four diagrams.
These diagrams show the boundaries procurement teams usually ask about first: read-only cloud roles, tenant-scoped access, credential encryption, and the envelope-key boundary around stored secrets.
Procurement review context
Built to survive the security review table.
The page is intentionally specific about roles, tenant boundaries, encryption, and runtime exposure. Security teams should be able to trace each claim back to a concrete control, not a badge or slogan.
01 · SECURE IDENTITY & ROLE PERMISSIONS
Clear, bounded permissions.
Least-privilege read-only permissions: Azure Service Principals (Reader + Cost Management Reader), AWS IAM Roles (read-only audit scopes), and GCP Workload Identity Federation. All roles are configured on your side, so scopes are enforced directly by your cloud providers, not by our promises.
Requested & Allowed Scopes
Azure Service Principal RolesScope: Reader + Cost Management Reader
Used to safely inspect Azure resource inventory, SKU types, utilization metrics, and cost management records across connected subscriptions.
AWS IAM Audit RoleScope: Auditable Read-Only Permissions
Used to analyze resource parameters and gather cost datasets under a secure, customer-controlled External ID policy.
GCP Workload Identity / Service AccountScope: OIDC / BigQuery Billing Read Scope
Used to securely connect Google Cloud billing exports and query resource configurations without long-lived credentials.
Refused & Blocked Scopes
Contributor / Owner / Write Roles
Write or update permissions are strictly refused. Ingestion clients across Azure, AWS, and GCP are structurally read-only, preventing any resource modification or deployment.
Storage / Database Payload Access
We never request write or deletion access on storage blocks, databases, or keys. We ingest cost metadata only, never raw application or customer database payloads.
02 · DATA-FLOW PIPELINE
Where credentials touch.
Service Principal keys are decrypted in one place: inside worker processes. The public-facing API never holds decrypted credentials in memory.
Vault security structure · decrypted inside workers
01
Clerk JWT · Org Scoped
Client Browser
Every request carries a Clerk JWT. The organization ID is read from the verified token, never from the request body, so one tenant cannot address another's data.
02
SSL/TLS · Envelope Encryption
NestJS API Gateway
Submitted Service Principal, IAM role configurations, and access keys are encrypted with AES-256-GCM before they are stored. The API does not decrypt them.
03
Task Queue · Reference Only
BullMQ / Redis
Audit jobs are dispatched to workers by reference ID. Credentials, decrypted payloads, and billing records never enter the queue.
04
AES-256-GCM In-Memory Decryption
Isolated Workers
Workers are the only processes that decrypt credentials, in memory and only while a job runs. They are separate from the public-facing web servers.
05
HTTPS REST APIs · Read-Only Scopes
Cloud Provider REST APIs
Workers query cloud endpoints over TLS using only read-only roles and APIs. Resulting metadata is stored in Postgres with deny-by-default row-level security.
03 · CRYPTOGRAPHY & ISOLATION
Security specifications
How credential storage, tenant isolation, billing, and operator access work in production. Each claim maps to a specific mechanism.
Credential Isolation
Credentials are encrypted with AES-256-GCM at rest. Decryption happens only inside worker processes, never in the web or API tier.
Multi-Tenancy
The organization comes from the verified Clerk JWT on every call, and application queries are scoped by organizationId. Database row-level security is an additional public API boundary, not a substitute for server-side tenant checks.
No-Write Code Paths
The Azure, AWS, and GCP packages are designed around read-only clients, and Costframe has no cloud-remediation write path. Customer-side least-privilege IAM remains the final enforcement boundary.
Billing Integrity
Payments run through Stripe. Costframe never handles or stores card details or bank credentials.
Data Deletion & Revocation
Deleting a connection purges its credentials from our storage. Revoking the Service Principal, IAM role, or OIDC federation on your side cuts access completely.
Operator Access
Platform administrators have cross-tenant read-only access, limited to an explicit PLATFORM_ADMIN_USER_IDS allowlist read by the API.
04 · TRANSPARENT LIMITATIONS
What Costframe cannot do.
Costframe analyzes cost and utilization data. It does not touch infrastructure, and the limits below are structural, not configuration.
With Costframe's read-only provider model, these actions are outside the platform's cloud-provider operating scope:
✕
No Resource State Changes
We cannot shut down virtual machines, pause Kubernetes clusters, delete snapshots, or alter scale sets.
✕
No Network & Security Access
We cannot adjust Network Security Group (NSG) rules, modify firewall scopes, or change routing configurations.
✕
No Active Node Deployment
We cannot deploy new nodes, allocate databases, provision subscription limits, or scale pricing tiers.
05 · TRUST FAQ
Frequently asked security questions
Is Costframe SOC 2 Type II certified?
Not certified Costframe maps relevant repository controls—such as tenant scoping, encryption at rest, and least-privilege access—to common SOC 2 procurement review areas. That mapping is not an audit opinion, attestation, or certification.
How is my data deleted?
Deleting a connection in your settings purges its credentials from our database. To sever access on your cloud provider side as well, revoke the Azure Service Principal, AWS IAM role, or GCP Workload Identity Federation OIDC connection.
Does Costframe collect or read database payloads?
No. Costframe queries read-only cloud APIs for resource metadata (ARM, AWS Config, GCP Cloud APIs), utilization metrics, and billing exports. There is no mechanism to query your application databases, file shares, or user data.
Who should I contact for a formal security review?
Use the contact page to scope a review. We complete security worksheets and provide architecture detail for enterprise evaluations.
Turn cloud waste into a verified action list.
Configure read-only access, run the first audit, and review the findings with engineering and finance at the same table.