Zero Egress. Local Sovereignty. Read-Only Access.
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.
Because AIPrunr operates as a self-hosted appliance, you retain absolute sovereignty over your data.
We enforce industry-standard encryption for data at rest and in transit.
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.
Attach this policy to the IAM User or Role used by AIPrunr. It grants strictly read-only access to cost and usage data.
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.
We understand the rigor of corporate security procurement. To accelerate your internal approval process, we provide a pre-packaged **Security Pack** under NDA.
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:
We publish a Software Bill of Materials (SBOM) with every release. We patch critical CVEs within 48 hours of disclosure.