Security brief

AWS connection model

ZephMatrix connects to your AWS account through a cross-account IAM role that you create and control. You paste the role ARN into ZephMatrix — no long-lived credentials, no access keys stored. The role grants only what the platform needs to investigate cost signals:

• • Cost and billing data — Cost Explorer, Cost and Usage Reports
• • Resource inventory — EC2, EBS, RDS, ELB, S3 metadata, EKS/ECS
• • Tags and resource configuration — for owner attribution and IaC detection
• • Utilization metrics — CloudWatch CPU, network, storage metrics
• • Commitment coverage — Savings Plans and Reserved Instance utilization

You can review and revoke the role at any time from your AWS IAM console. Setup takes under ten minutes.

What ZephMatrix never accesses

The IAM role is scoped to cost, inventory, tags, and metrics. It does not include:

• • S3 object contents, database records, or application data of any kind
• • Secrets Manager or Parameter Store values
• • IAM credentials, key pairs, or access key material
• • CloudTrail management events or identity-sensitive logs
• • VPC traffic, flow logs, or packet-level data

The platform only ever reads cost data, resource inventory, tags, and utilization metrics — nothing broader.

Infrastructure-changing actions

ZephMatrix can stop/start scoped EC2 instances, delete orphaned EBS volumes and snapshots, release unused Elastic IPs, and route idle load balancers for owner review. Every one of these actions requires explicit human approval before execution — the agent never acts autonomously on infrastructure.

• • Safety classification runs before any action is routed: production, ASG-managed, and IaC-managed resources are flagged
• • An approval card surfaces in the ZephMatrix UI with the finding, owner context, and proposed action
• • The agent cannot execute an infrastructure action unless a human approves it in that card
• • Approve and reject decisions are recorded and tied to the originating finding

Audit trail and verified outcomes

Every finding that enters the investigation loop produces a traceable record:

• • Finding → case assembly → approval decision → execution → verified outcome
• • Baseline cost captured before execution, rechecked after — savings are confirmed or flagged, not estimated
• • Full case history is retained: who approved, what ran, what the outcome was

What is not implemented yet

Formal third-party attestations (SOC 2 report issued by an auditor) and advanced data residency controls are on the roadmap. This page reflects controls that are enforced in code today.