How Aithrex runs inside your AWS account.
The trust model in plain language: where the agent runs, what it reads, what it never touches, and the one command that halts everything.
Trust is engineering, not marketing.
We do not list certifications we have not earned. Instead, we describe the properties of how the system runs, so your security team can verify each one.
In-account by default
Scoped IAM, least privilege
Customer-held kill switch
Audit trail, no surprises
Explicit about scope, not vague about it.
Architecture-aware reasoning needs resource metadata, not application data. Below is what the agent reads, what it does not read, and what it never applies without.
- Resource metadata: VPCs, subnets, route tables, security groups, IAM roles/policies, S3 buckets, EC2/EKS/RDS configuration
- Cost & usage signal from Cost Explorer and CloudWatch metrics needed for the finding
- VPC flow log shape (path-level, not packet content) where you've already exported it
- Application data inside S3 buckets, RDS rows, or any workload payloads
- Secrets, parameter store values, KMS plaintext, or anything that decrypts customer data
- CloudTrail entries unrelated to the resources we're reasoning about
- A plan reviewed by your team
- An action-scoped IAM role you've authorized
- A stored inverse operation attached to the change
Two roles, both yours.
Onboarding creates two IAM roles in your account from a documented Terraform template. InfratrixDiscoveryRole is read-only and used for graph construction. InfratrixActorRole is scoped per-action-class and is only assumable to apply a plan you have explicitly approved.
Both roles live in your account. There is no cross-account trust granted to a long-lived Aithrex-side identity for production writes — every write session is short-lived and audit-logged.
The full template, including comments on every Action, is shared during onboarding and reviewed before any role is created.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "InfratrixDiscoveryReadOnly",
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"ec2:Get*",
"vpc:Describe*",
"elasticloadbalancing:Describe*",
"iam:Get*",
"iam:List*",
"s3:GetBucketLocation",
"s3:ListAllMyBuckets",
"s3:GetBucketTagging",
"cloudwatch:GetMetricData",
"ce:GetCostAndUsage"
],
"Resource": "*"
}
]
}Excerpt. The actor role uses a separate template with per-actionCondition blocks.
One revocation. Everything stops.
The trust path is the IAM role. There is no second credential, no SaaS-side backup, no support-engineer bypass. If you delete the two roles, every Aithrex agent loses access to your account immediately.
We test this on every onboarding. A successful kill-switch drill is part of the go-live checklist — before any production write role is created.
# One command halts every Aithrex action in this account.
aws iam delete-role --role-name InfratrixDiscoveryRole
aws iam delete-role --role-name InfratrixActorRoleTested on every onboarding. Documented in the runbook your team keeps.
We will not claim what we have not built.
Below is the same status table we keep on the company page — the one that decides what we are allowed to say about ourselves.
- Infratrix — architecture-aware optimization for AWS
- Graph-grounded reasoning across real account state
- Terraform-shaped, review-ready change proposals
- In-account agents with customer-held IAM kill switch
- Cross-cloud reasoning beyond AWS
- Review-first execution patterns for SRE workflows
- Architecture-aware posture and compliance signal
- Compliance certifications (SOC 2, ISO 27001, HIPAA)
- Named customer logos, case studies, or testimonials
- Guaranteed savings percentages or dollar amounts
- Fully autonomous production remediation
Bring your security team. We’ll walk the model with them.
Thirty minutes on a call, with whoever needs to sign off. We answer in plain language and ship the IAM template before the second meeting.