Security & Compliance

Zero Egress. Local Sovereignty. Read-Only Access.

View System Architecture Diagram

1. The Zero Egress Promise

At AIPrunr, we believe that the best way to secure your data is not to touch it. Our architecture is fundamentally designed around "Zero Egress" and strict least-privilege principles.

AIPrunr runs entirely within your infrastructure (On-Premise or Private Cloud). Your credentials, cloud resource data, and financial insights never leave your network.

2. Data Handling & Residency

Because AIPrunr operates as a self-hosted appliance, you retain absolute sovereignty over your data.

  • Data Residency: All data stored by AIPrunr resides on the disk of the machine where you install it. We have no cloud database that mirrors your sensitive information.
  • Data Retention: You control the retention period. You can purge data at any time using the built-in "Data Purge" tools in the dashboard.
  • No Telemetry: The appliance does not send usage metrics, crash reports, or metadata to AIPrunr HQ.

3. Encryption Standards

We enforce industry-standard encryption for data at rest and in transit.

  • At Rest: If you use our encrypted credential storage, API keys are encrypted using AES-256-GCM before being written to the local database.
  • In Transit: The dashboard is served via HTTPS (with HSTS enabled). All calls to your cloud providers (AWS, Azure, GCP) use TLS 1.2+ encrypted channels.

4. IAM Read-Only Access Model

AIPrunr requires Read-Only permissions to function. We never ask for write or delete permissions on your cloud resources. This ensures that a compromised AIPrunr instance cannot disrupt your production services.

Sample AWS IAM Policy

Attach this policy to the IAM User or Role used by AIPrunr. It grants strictly read-only access to cost and usage data.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AIPrunrReadOps", "Effect": "Allow", "Action": [ "ce:GetCostAndUsage", "ce:GetCostAndUsageWithResources", "ce:GetCostForecast", "ec2:DescribeRegions", "ec2:DescribeInstances", "ec2:DescribeVolumes", "ec2:DescribeSnapshots", "ec2:DescribeAddresses", "ec2:DescribeNatGateways", "s3:ListAllMyBuckets", "s3:GetBucketLocation", "rds:DescribeDBInstances", "rds:DescribeDBClusters", "cloudwatch:GetMetricStatistics", "elasticloadbalancing:DescribeLoadBalancers" ], "Resource": "*" } ] }

One AWS-side step this policy alone doesn't cover: per-resource cost data additionally requires "Resource-level data" to be opted into from the Cost Explorer Settings page in the AWS Billing Console (a console setting, not an IAM grant) -- until that's on, discovered assets will show without dollar figures.

Note on the "elasticloadbalancing" action: this single action covers both Classic Load Balancers and modern Application/Network Load Balancers -- AWS uses one IAM action namespace for both APIs, so no separate "elasticloadbalancingv2" permission exists or is needed.

Note on the "cloudwatch:GetMetricStatistics" action: this is used only to read each RDS instance's own real CPU utilization history (AWS/RDS namespace) so rightsizing suggestions are based on actual usage rather than left unavailable -- it grants no ability to view logs, alarms, or any other account's metrics. Without it, RDS CPU utilization simply stays unmeasured (reported as 0%, never guessed).

Scanning an entire AWS Organization (optional): the policy above is everything needed for a single AWS account. To auto-discover every account in an AWS Organization instead, the credential configured in AIPrunr (typically in the management/payer account) additionally needs organizations:ListAccounts and sts:AssumeRole (scoped to the target role's ARN in each member account) -- these are separate from, and granted on top of, the read-only policy above, since they belong to the account doing the assuming rather than the account being read.

Equivalent read-only grants for OCI and Azure: OCI additionally needs a tenancy-level policy granting read usage-report in tenancy (cost data in OCI is tenancy-wide, not compartment-scoped). Azure additionally needs the built-in Cost Management Reader (or Billing Reader) role assigned alongside the Reader role already used for discovery.

GCP: additional permission for Cloud Run request-volume data: reading how much real traffic a Cloud Run service has taken (used to detect genuinely idle services, rather than guessing) requires the service account used by AIPrunr to also hold roles/monitoring.viewer on the project, granted alongside whatever discovery role is already in use.

5. Security Review Simplified

We understand the rigor of corporate security procurement. To accelerate your internal approval process, we provide a pre-packaged **Security Pack** under NDA.

Enterprise Security Pack Includes:

  • SIG Lite Questionnaire: Pre-filled with forensic technical details.
  • ISO 27001 Roadmap: Detailed alignment for your ISMS audit.
  • SOC 2 Type II Gap Analysis: Transparent view of our security posture.
  • Reference Architecture: Deep-dive into VPC/NSG flow log ingestion.
Request Security Pack

6. Trust & Malware Defense

Because the AIPrunr appliance runs as a local binary/container in your network, we design the product to be transparent, auditable, and secure against malware flags:

  • Agentless Security: AIPrunr operates strictly out-of-band and never executes binary code or installs software on your production servers or virtual machines.
  • Zero Outbound Connectivity Required: You can run the AIPrunr appliance in a completely air-gapped, internet-disabled subnet. The appliance operates fully locally and does not require outbound internet access to perform its audit functions.
  • Vulnerability & Integrity Scanning: The container image and virtual appliance files are compiled cleanly and are open to inspection by package scanners (e.g., Snyk, Trivy, Aqua) prior to execution.

7. Vulnerability Management

We publish a Software Bill of Materials (SBOM) with every release. We patch critical CVEs within 48 hours of disclosure.