Least privilege
Users, agents, and workflow steps receive only the access required for their authorized function.
- Title
- Security overview
- Version
- 2026.09
- Effective date
- as posted
- Last updated
- as posted
- Contact
- security@amazflow.com
- Maintainer
- CLO (content); IT (facts)
SECURITY & TRUST
Built to do the work.
Built to earn the access.
Operational execution requires more than a clever model. AmazFlow is designed around constrained authority, customer control, verifiable outcomes, and clear accountability.
Tenant isolation
Customer-scoped entities and requests are separated and enforced server-side.
Execution controls
Allowlisted actions, short-lived tasks, approvals, expiration, verification, retries, and revocation.
Encryption and secrets
Encryption in transit and at rest with managed secret references rather than embedded credentials.
Audit history
Material workflow actions record actor, method, policy, timing, result, and approval context.
Secure delivery
Infrastructure as code, testing, code review, dependency scanning, and vulnerability remediation.
AI governance
Structured outputs, bounded choices, confidence thresholds, policy enforcement, and human oversight.
Regulated data
BAA-supported deployment options are available for eligible HIPAA-regulated workflows.
DEPLOYMENT MODEL
What's actually running, on AWS.
AmazFlow's control plane is AWS-native and tenant-scoped by construction, not by convention layered on afterward.
Control plane
A dedicated, encrypted DynamoDB table with point-in-time retention holds every workflow definition and execution record.
Audit log
A retained CloudWatch log group captures execution and access events separately from the application data store.
Identity & roles
AWS Cognito enforces three access tiers — Frontline user, Client operations admin, and AmazFlow super admin — each with a fixed permission set.
Tenant isolation
Every account carries a tenant claim enforced server-side on every request; the API rejects cross-tenant access even when a client knows another object's identifier.
AI and agent runtime
Model-driven interactions run through Amazon Bedrock AgentCore Harness, Gateway, Policy, Memory, Browser, Evaluations, and Observability services. Workflow state, approvals, confirmations, verification, and audit truth remain in AmazFlow's deterministic control plane.
Execution surface
API Gateway and Lambda front the control plane; browser-based execution runs through short-lived, tenant-scoped agent tasks with an explicit operation allowlist, not standing credentials.
CURRENT VS. FUTURE READINESS
Where AmazFlow stands today.
Today: the controls above are live in the deployed architecture. AmazFlow is building toward SOC 2 readiness but does not currently claim a SOC 2 examination or attestation. We do not make blanket “HIPAA compliant” claims. Audit and evidence history is part of the live control plane; retention commitments for Evidence Records are set in the customer agreement, not by a certification badge.
In progress: for eligible customer deployments, AmazFlow is prepared to evaluate and execute appropriate BAAs and restrict regulated data to approved architecture and subprocessors — this is scoped per engagement, not a standing certification.
Evidence and audit history
Material workflow actions record actor, method, policy context, timing, result, and approval context. Evidence packs document that a run occurred, which verification checks ran, and which human approvals were required — they do not certify business outcomes or create a compliance attestation.
Retention of Evidence Records is governed by the customer agreement (MSA and Order Form) and the Data Processing Agreement. See also the Privacy Policy retention schedule for related categories.
Security inquiries and responsible disclosures can be sent to security@amazflow.com. Privacy requests can be sent to privacy@amazflow.com.