Security Model, Coverage & Limitations

How Securitain accesses AWS, what information it processes, how governance and remediation are separated from scanning, and what the platform does not claim.

Securitain is designed to provide AWS security visibility without requiring standing administrative control over customer AWS resources. For service-by-service assessment coverage, also see Supported AWS Services & Coverage.

Security principles

Truth before presentation

Securitain does not claim a scan, finding, score, AI analysis, report or remediation occurred unless the corresponding backend action or evidence exists. This is why Securitain avoids fake or demo results in production views.

AWS access model

Customer-controlled AWS access

Customer AWS access is established through a role created inside the customer AWS account. The customer controls the role, trust policy, CloudFormation stack and the ability to revoke or delete it.

Temporary AWS sessions

Securitain uses AWS STS AssumeRole for assessment sessions. Temporary STS credentials are used during the assessment execution. Customers do not supply a permanent IAM access key or secret key for standard Securitain onboarding.

External ID

The cross-account trust uses a connection-specific External ID. External ID helps mitigate confused-deputy risk for the SaaS cross-account relationship. Public security statements should say:

• generated server-side
• connection-specific
• used in role trust and AssumeRole
• omitted from routine account API responses
• treated as security-sensitive connection configuration

Read-oriented AWS access

The current Securitain scanner is designed for assessment rather than customer AWS mutation. The customer role uses read-oriented API capabilities such as List, Get, Describe and supported policy simulation or read operations. The exact service permission contract is documented in Supported AWS Services & Coverage and is visible in the customer CloudFormation setup.

Customer-inspectable CloudFormation

The AWS role is created using a customer-reviewed CloudFormation template. The customer can inspect requested permissions before deployment. A core security objective is: do not hide AWS permissions from the customer. If Securitain expands service coverage, the CloudFormation permission model should be updated transparently.

No standard scanner write authority

The standard Securitain assessment role should not contain AWS mutation permissions. Current remediation proposes, explains and provides manual or CLI or Terraform guidance. The customer executes the change.

Remediation separation

Read-oriented assessment role
       ↓
Finding
       ↓
Remediation guidance
       ↓
Customer-controlled change
       ↓
Read-oriented verification scan

AI separation

Base production AI tools should remain read-only. AI cannot:

• change its own authorization
• self-approve remediation
• use natural-language conversation as a substitute for explicit approval

AI recommendations and artifacts remain drafts unless a separately governed execution workflow is introduced.

Data and evidence

Tenant isolation

Securitain is multi-tenant. Customer data access must be restricted to the authorized Securitain organization and user scope across API, database, workers, reports, exports, AI and integrations. No answer or report may include another customer's data.

Authorization

Product actions can depend on authenticated user, organization membership, user role, entitlement and account scope. High-impact workflows such as exception approval and account purge can require stronger organization authorization.

Evidence-backed security

A security conclusion should preserve enough context to answer: Why did Securitain say this? Supported evidence can include account, region, resource or identity, scan, collection time, policy or trust information and finding evidence. Not every result has every field.

Scan provenance and freshness

Securitain distinguishes current or newest scan state from last successful data-producing assessment. A failed new scan should not erase previously collected data. A report generated now may rely on evidence collected at an earlier point. Use Scan Status & Freshness when making time-sensitive decisions.

Data processed by Securitain

Securitain processes supported AWS security and configuration metadata needed for the product's assessment capabilities. Examples can include:

• IAM identities
• policy documents
• trust policies
• account metadata
• security configuration
• resource metadata
• supported activity or evidence

The exact public collection scope is defined by Supported AWS Services & Coverage.

Secret values

Securitain minimizes collection of raw secret values. The product does not need customer IAM secret access keys, workload secret values or application passwords for normal AWS posture analysis. Secret-management security analysis should rely on metadata and access policy where supported rather than reading secret contents.

Credentials created by STS

Temporary STS credentials are operational credentials used during role-assumption sessions. They must not be exposed to users or the browser, included in exports or logged in raw form.

Data classification

Securitain treats customer security evidence as sensitive customer data and protects it using access controls and encryption requirements.

Encryption

Current product requirements protect customer data and evidence in transit using TLS and at rest using approved storage encryption.

Retention and deletion

Data retention depends on product, contract policy, account lifecycle and evidence or report retention. Customers can use account offboarding to disconnect, revoke AWS access and permanently purge account data where supported. See AWS Accounts Administration.

Auditability

Security-relevant workflows preserve audit history where appropriate. Examples include finding status history, exception approval, account offboarding, AI tool usage and scan history.

Shared responsibility

Security depends on both Securitain and the customer.

Securitain responsibilities

• protect the Securitain service
• enforce tenant and user authorization
• restrict AWS scanner permissions to intended read capabilities
• generate and protect connection context
• preserve evidence and freshness
• secure product data in transit and at rest
• avoid secret leakage
• provide truthful capability and error states

Customer responsibilities

• review and deploy the AWS role and CloudFormation stack
• control the AWS account and CloudFormation stack lifecycle
• maintain appropriate AWS security configuration
• decide who has Securitain access
• review findings and evidence
• execute remediation changes
• make risk-acceptance decisions
• revoke AWS role when offboarding
• protect exported security reports

AWS responsibility

AWS remains responsible for security of the AWS cloud infrastructure and managed-service responsibilities under the AWS shared-responsibility model. Customer and Securitain responsibility depends on the particular AWS control and service.

Assessment limitations

Securitain is intentionally transparent about what a scan can and cannot prove.

Point-in-time assessment

Securitain scans represent the AWS state observed during an assessment. They are not a guarantee that configuration remains unchanged between scans.

Supported-service scope

Supported-region scope

Regional services may have documented region limitations. Do not infer all-region coverage from one successfully scanned region.

Permission-limited assessment

If the customer role cannot read required information, the relevant capability can be partial or unavailable. This is not a pass.

IAM authorization limitations

AWS authorization can depend on runtime context such as request attributes, session policies, tags, service-specific conditions, resource policies, explicit denies and organization controls. Securitain's Effective Permissions and path analysis are evidence-backed analysis. They are not a substitute for the final AWS authorization decision for every possible runtime request.

Trust limitation

A trust relationship does not automatically mean successful access. Successful AssumeRole can depend on caller permission, trust conditions and AWS context.

Attack-path limitation

A detected attack or escalation path identifies a security-relevant supported capability chain. It does not prove compromise occurred, that the path was used or that every runtime precondition will always succeed.

Blast-radius limitation

Blast radius is potential consequence and prioritization context. It is not breach probability, a percentage of account controlled or an exact resource count guarantee.

Least-privilege limitation

Historical absence of observed usage does not prove access is unnecessary. Least Privilege recommendations require workload-owner validation.

Data Security limitation

Current Data Security is AWS resource posture and security metadata analysis. Unless separately documented, it is not content-level data classification, malware scanning, packet inspection, database query monitoring or proof of network reachability.

Compliance limitation

Compliance mapping connects technical findings to relevant control references. It is not certification, attestation, legal advice or a full audit of organizational, process or physical controls.

AI limitation

AI answers can be incorrect or incomplete. Production AI should be grounded and cited, but evidence can be partial, scans can be stale and models can misinterpret. Use source evidence for high-impact decisions.

Remediation limitation

Current remediation is guidance. Securitain does not currently claim that clicking Apply changed AWS. A finding is not Remediated until a capable scan verifies the condition is absent.

No guarantee of complete risk absence

0 findings from Securitain
=
No finding produced for supported checks in assessed scope

≠
Zero AWS security risk
≠
All services assessed
≠
All regions assessed
≠
All runtime conditions evaluated

Demo/sample data

Sample or demo information must be clearly distinguished from customer evidence. Production customer views must not fabricate findings, scan completion, risk scores or AI conclusions. This is a formal product credibility principle.

Offboarding and revocation

Customers can stop Securitain AWS access by removing or revoking the customer-side role and CloudFormation stack. Securitain's application disconnect is separate from AWS-side revocation. See AWS Accounts Administration.

Related guides