Documentation
NHI Security Platform — 13 finding types, proprietary Policy Intelligence Engine™, and Terraform fix PRs. Get from zero to first IAM fix in under 10 minutes.
Quick Start (5 min)
1. Create the TrustFix IAM Role in AWS
TrustFix uses a read-only cross-account IAM role to scan your AWS account. Create it with the following trust policy, replacing TRUSTFIX_ACCOUNT_ID and YOUR_EXTERNAL_ID with the values shown in your TrustFix dashboard.
Attach an IAM policy with the minimum required permissions: iam:ListRoles, iam:GetRole, iam:GetRolePolicy, iam:ListRolePolicies, iam:ListAttachedRolePolicies. TrustFix never writes to your AWS account.
2. Add the GitHub Actions Workflow
Add the TrustFix scanner to your existing CI workflow or create a dedicated security scan file. This runs on every push and PR.
Add TRUSTFIX_ROLE_ARN as a GitHub Actions secret with the ARN of the IAM role you created in Step 1.
3. Connect Your AWS Account in the TrustFix Dashboard
After signing in to TrustFix:
- Go to AWS Accounts → Connect Account
- Enter the ARN of the IAM role you created in Step 1
- Enter the External ID shown on the connection form (must match your trust policy)
- Click "Connect" — TrustFix will verify the connection via STS
Your first scan runs automatically when you connect your AWS account. Findings appear within 60 seconds. Critical issues are highlighted in red with severity ratings. Starter and Pro plans include on-demand rescanning via the Scan Now button.
Security Model
TrustFix is designed with a least-privilege, read-only security model. Here is exactly what access we require and why.
Cross-Account IAM with External ID
TrustFix assumes a role in your AWS account using STS AssumeRole with a unique External ID. The External ID prevents confused deputy attacks — only TrustFix, from our specific AWS account, can assume your role even if an attacker knows your role ARN.
Read-Only IAM Permissions
The role requires only the following four permissions — nothing more:
No Write Access — Ever
TrustFix never modifies your AWS environment. All fix recommendations are delivered as GitHub Pull Requests that require human review and approval before anything changes. There is no automated remediation that touches AWS directly.
Temporary STS Credentials
Every scan uses fresh temporary credentials obtained via STS AssumeRole. These credentials expire automatically and are never stored to disk or logged. TrustFix never stores AWS access keys or secret keys of any kind.
Detection Reference
TrustFix currently detects 13 distinct IAM misconfigurations across four categories: GitHub Actions OIDC trust policies, overprivileged CI/CD roles, AI agent identities, and cross-account / static-credential patterns.
| # | Detector | What It Detects | Severity |
|---|---|---|---|
| 1 | Missing Sub Condition | OIDC trust policy has no token.actions.githubusercontent.com:sub claim — any repo in any GitHub org can assume the role | CRITICAL |
| 2 | Overly Broad Trust | Sub condition uses StringLike with wildcards (repo:*:* or repo:myorg/*) — matches unintended repositories | CRITICAL |
| 3 | Missing Audience Condition | No aud condition — tokens minted for any OIDC client are accepted | HIGH |
| 4 | Fork PR Risk | Workflow grants id-token: write on pull_request trigger — a fork PR can mint an OIDC token and assume the role | HIGH |
| 5 | Wildcard Environment | environment:* wildcard in the sub claim bypasses GitHub Environment protection rules and required reviewers | HIGH |
| 6 | Expired OIDC Provider | Stale OIDC provider thumbprint, or provider deleted entirely — role is either dead or trusting an obsolete certificate | MEDIUM |
| 7 | Overprivileged CI/CD Role | Role grants permissions broader than what the attached workflows actually use (measured against the last 90 days of CloudTrail activity) | HIGH |
| 8 | Admin Access in CI/CD | AdministratorAccess (or equivalent Action: "*" / Resource: "*") attached to a CI/CD role — a compromised workflow owns the entire AWS account | CRITICAL |
| 9 | AI Agent Overprivileged | LLM or AI agent role granted broad bedrock:*, s3:*, or secretsmanager:* permissions — prompt injection turns into data exfiltration | CRITICAL |
| 10 | AI Agent Missing Scope | AI agent trust policy missing scope/tool-restriction conditions — the agent can assume authority beyond its intended task surface | HIGH |
| 11 | Cross-Account Trust: Missing ExternalId | Cross-account sts:AssumeRole trust lacks the sts:ExternalId condition — classic AWS confused-deputy vulnerability | HIGH |
| 12 | Cross-Account Trust: Wildcard Principal | Trust policy allows Principal: "*" or arn:aws:iam::*:root — any AWS account on Earth can assume the role | CRITICAL |
| 13 | GitHub Static Credentials | GitHub Actions workflow uses long-lived AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY secrets instead of OIDC — recommend migration to federated credentials | HIGH |
Vulnerable policy example:
Fixed policy example:
oidc-audit CLI (Open Source)
Run TrustFix's OIDC scanner locally — no account required. The CLI scans your AWS account's IAM roles for OIDC misconfigurations and outputs findings in JSON or human-readable format.
Also available as a GitHub Actions step — scan on every push and PR automatically. View on GitHub Marketplace →
Frequently Asked Questions
Does TrustFix have write access to my AWS account?
No. TrustFix uses a read-only cross-account IAM role to scan your account — we recommend the curated least-privilege CloudFormation/Terraform template, which grants only the specific read actions needed and never reads secret, parameter, or S3 object values (the broader AWS-managed ReadOnlyAccess policy also works as a fallback). All fix recommendations are delivered as GitHub Pull Requests that require human review and approval before anything changes in your infrastructure. TrustFix never auto-applies changes.
Does TrustFix store my AWS credentials?
No. TrustFix never stores AWS access keys or secret keys. All AWS access is via temporary STS credentials obtained by assuming your cross-account IAM role. These credentials expire automatically and are never written to disk.
What Terraform providers are supported?
TrustFix generates fixes for the AWS provider (hashicorp/aws) version 4.x and above. Generated Terraform uses the aws_iam_role resource with a trust policy document. If you use a different IaC tool (CDK, CloudFormation, Pulumi), you can still use the JSON trust policy shown in each finding to apply the fix manually.
How does the AI fix generation work?
When you request a fix, TrustFix sends the specific IAM trust policy and finding details to an AI service. The AI analyzes the trust relationship, identifies the exact misconfiguration, and generates a least-privilege Terraform patch. The generated code targets only the affected condition block — it does not rewrite unrelated parts of your IAM role.
Ready to scan your IAM roles?
TrustFix is invitation-only while we onboard our first enterprise customers. Try the open-source CLI in the meantime.