Keep trust boundaries visible before access is granted.

1. Trust model overview

Security starts with a smaller trust surface.

This page describes the current security approach. It is not a claim of third-party certification.

• Customer-owned runtime Application workloads continue to run in the customer AWS account rather than moving onto a Zerverless runtime.
• On-demand AWS access Connections use an approved role ARN and unique external ID so roles can be assumed through AWS STS when required.
• Separate read and write roles Discovery and analysis cannot silently become deployment access. Write access requires a different role and decision.

2. Account boundaries

The customer account remains the system boundary.

• No long-lived customer credentials Customer connections store a role ARN and unique external ID, not access keys or secret keys.
• Permissions follow the product Each role is scoped to the resources and actions required by the selected workflow. Wildcard permissions are not requested for convenience.
• Revocation stays with the customer A customer can remove the trusted role or its permissions in AWS to end that access path.
• Customer code stays in AWS Zerverless manages product and account context; it does not become the runtime for customer application code.

3. Connecting an AWS account

Treat every AWS connection as an explicit decision.

• 01. Choose the product The job determines whether no AWS access, read-only access, or a separate deployment path is required.
• 02. Review the role The customer reviews the trust relationship, external ID, requested actions, and resource scope before creating a role.
• 03. Assume on demand Approved roles are assumed through AWS STS for the selected workflow instead of storing customer access keys.
• 04. Revoke in AWS Removing or changing the customer role ends or narrows the access path at the source of authority.

4. Ongoing security practices

Security continues beyond the initial connection.

• Identity and authorization Organization, entitlement, account, role, and product checks remain distinct so one successful check does not imply every other permission.
• Data minimization Collect and retain only the account metadata and user-provided information needed for the selected product or engagement.
• Dependency and change review Review security-relevant updates for runtime and AWS impact, then validate them with workspace checks before deployment.
• Incident priority Suspected unauthorized customer-account access, credential exposure, or authentication and entitlement bypass receives immediate triage priority.

5. Customer responsibilities

Security remains a shared responsibility.

• Review role templates and requested permissions before deployment.
• Control who can create, change, or remove trusted roles in AWS.
• Protect dashboard identities and enable available account-security controls.
• Report unexpected access, role changes, or product behavior promptly.

6. Zerverless responsibilities

• Keep product authorization and AWS role boundaries separate.
• Request only the access required for the selected workflow.
• Avoid storing long-lived customer AWS credentials.
• Triage credible vulnerability reports and communicate appropriate next steps.