How plainfra Keeps Your Infrastructure Safe

1. The IAM role: read-only with explicit denials

When you connect your AWS account, you deploy a single CloudFormation stack that creates an plainfra-ReadOnly IAM role. This role has two policies:

• Policy 1 — Infrastructure discovery (Allow). Explicit list of read-only describe, list, and get-metadata actions across EC2, Lambda, ECS, EKS, RDS, DynamoDB, S3, CloudWatch, IAM, CloudTrail, Config, GuardDuty, SecurityHub, Cost Explorer, and related services. Every permitted action is named individually — there are no wildcard * permissions and no AWS-managed policies.
• Policy 2 — Explicit data access denial (Deny — always wins). A hard Deny block that overrides everything else, regardless of what any future policy might grant:
  • s3:GetObject, s3:GetObjectVersion — cannot read file contents
  • dynamodb:GetItem, dynamodb:Query, dynamodb:Scan — cannot read table rows
  • secretsmanager:GetSecretValue — cannot read secret values
  • ssm:GetParameter, ssm:GetParametersByPath — cannot read secure strings
  • logs:GetLogEvents, logs:FilterLogEvents — cannot read log content
  • kms:Decrypt, kms:GenerateDataKey — cannot decrypt anything
  • kinesis:GetRecords — cannot read stream data
  • sqs:ReceiveMessage — cannot read queue messages
  • lambda:InvokeFunction — cannot execute your functions
  • ec2:GetConsoleOutput, ec2:GetPasswordData — cannot access VM consoles
  • rds-data:ExecuteStatement — cannot run SQL queries

plainfra can tell you that an S3 bucket exists, when it was created, its versioning state, and its access control configuration. It cannot read a single byte of data stored inside it.

You can download the full CloudFormation template and verify every permission yourself before deploying. We encourage it — paste it into Claude or ChatGPT and ask it to explain exactly what the role can and cannot do.

2. Cross-account trust with ExternalId

The role trust policy restricts assumption to plainfra's AWS account (921514166437) and requires a unique ExternalId generated specifically for your account at signup. This prevents the confused deputy problem — even if an attacker knew plainfra's account ID, they cannot assume your role without your exact ExternalId. The ExternalId is never displayed in the UI after onboarding and is stored only as part of your encrypted account record.

3. API keys

Your plainfra API key is shown to you once — at the end of the signup flow and in the welcome email. We store only the SHA-256 hash of your key in DynamoDB. There is no way to recover your plaintext key from our systems. If you lose it, you contact support and we issue a new one.

API keys are prefixed with tt_ to make them identifiable in logs and secret scanners. We recommend treating your API key like a password: store it in a secrets manager, rotate it if you suspect compromise, and never commit it to source control.

4. Data storage and encryption

All plainfra infrastructure runs in AWS Sydney (ap-southeast-2). Your data never leaves Australia.

• DynamoDB. Customer account records, subscription state, and API key hashes. Encrypted at rest using AWS-managed keys.
• S3. Conversation history and generated reports, stored under your customer ID prefix. Encrypted at rest using AWS-managed keys. Conversation history is retained for 90 days; reports for 365 days.
• In transit. All communication between your browser, plainfra APIs, and AWS services uses TLS 1.2 or higher. There is no unencrypted path.

5. Payment security

Payments are handled entirely by Stripe, a PCI DSS Level 1 certified payment processor. plainfra never receives, stores, or processes your card number, CVV, or full card details. When you enter card details during signup, they go directly from your browser to Stripe's servers — our backend only receives a Stripe payment method token.

6. Infrastructure access controls

plainfra runs as serverless Lambda functions with no persistent servers or long-lived credentials. Production AWS access is restricted to named IAM roles with MFA-enforced console login. No engineer has long-term programmatic credentials to production systems. All infrastructure changes are made through CloudFormation with reviewed templates.

The plainfra Lambda functions themselves run with minimum-privilege execution roles scoped to only the DynamoDB tables, S3 bucket, and Bedrock APIs they need to operate.

7. AI and conversation data

Queries you send to plainfra and the infrastructure context gathered to answer them are processed by Claude via Amazon Bedrock. All inference runs within Australian AWS infrastructure. Conversation history is stored in S3 so plainfra can maintain context across sessions.

We do not use your conversation data to train any AI models. Amazon Bedrock's data handling policies apply to inference requests; Anthropic's zero-data-retention API agreement means your prompts and responses are not retained by Anthropic.

8. Revoking access

You remain in complete control of the IAM role at all times. To immediately revoke plainfra's access to your AWS account:

1. Log into your AWS Console
2. Navigate to CloudFormation → Stacks
3. Delete the plainfra-ReadOnly stack

This takes effect immediately. plainfra will no longer be able to query your account. Your account record and conversation history in plainfra's systems are retained per our Privacy Policy and can be deleted on request.

9. Vulnerability disclosure

If you discover a security vulnerability in plainfra, please report it to security@triont.com. We ask that you:

• Give us reasonable time to investigate and fix the issue before public disclosure
• Avoid accessing or modifying data that doesn't belong to you
• Not perform denial-of-service attacks or disruptive testing

We will acknowledge all reports within 2 business days and keep you informed as we investigate. We do not currently offer a formal bug bounty program, but we genuinely appreciate responsible disclosure and will credit researchers who want to be named.

10. Contact

For security questions or concerns: security@triont.com

For general support: support@triont.com