How Edict Labs Handles Your Cloud Credentials

The Problem We Solve

When you connect your AWS account to any third-party platform, you're making a trust decision. That platform can access your infrastructure, modify your resources, and potentially cause real damage.

Most platforms ask you to trust them. We took a different approach. We built an architecture where trust isn't required because safety is structural.

Here's how we handle your cloud credentials, what the architecture guarantees, and what happens if anything goes wrong.

Credential Lifecycle

Every credential issued by Edict Labs follows the same lifecycle. No exceptions.

Scoped. Every credential follows Principle of Least Privilege. Scoped to minimum permissions needed, nothing more. A credential issued for provisioning a VPC and RDS instance cannot touch S3 buckets, Lambda functions, or anything outside its authorized scope.

Ephemeral. Credentials are time-bound. They exist only for the duration of the work they were issued for. No standing credentials. No long-lived access keys. No stored secrets.

Auto-revoked. The moment the work completes, whether it succeeds or fails, the credential is revoked. If work takes longer than expected, the credential expires on its time boundary. A periodic sweep catches any orphaned credentials that weren't properly revoked.

Separation of Authorization and Execution

No single component can both approve and execute a privileged action on your infrastructure. This separation is architectural, not a policy layer bolted on top.

Three phases, each structurally isolated:

Planning. Determines what needs to be provisioned based on your request. This component has no cloud credentials whatsoever. It cannot take any direct action on your infrastructure. It can only propose what should happen.

Verification. Every proposed action is independently checked against policy. This component evaluates whether the action is allowed, but it has no ability to execute anything. It can approve or reject, but it cannot act.

Execution. Receives scoped, ephemeral credentials for the authorized work. This component knows nothing about policy. It only knows how to execute what it was authorized to perform.

Compromise any one of these in isolation and the attacker gets nothing useful:

• Compromise the planner: no credentials to steal.
• Compromise the verifier: no ability to execute.
• Compromise the executor: scoped credentials that no longer exist after completion.

What This Means in Practice

No shared credentials. Your AWS credentials are never stored as long-lived secrets. There is no vault of customer keys that could be breached. Every credential is derived on demand, scoped to minimum permissions, and destroyed after use.

No lateral movement. Even if an attacker gains access to a credential, they cannot use it to reach anything outside the authorized scope. The credential does not have permission to do anything beyond what it was issued for.

No privilege escalation. A compromised component cannot grant itself more access. The planning component cannot issue credentials. The verification component cannot execute operations. The execution component cannot modify its own scope. These boundaries are architectural, not policy-based. They cannot be bypassed by misconfiguration.

Tamper-evident audit trail. Every action is recorded in a hash-chained, append-only audit log. Each entry is cryptographically linked to the previous one. If any entry is modified or deleted, the chain breaks and the tampering is immediately detectable. Built to satisfy SOC 2 Type II and HIPAA evidence requirements for infrastructure change management.

Progressive Trust

We don't assume trust. We earn it.

When you first connect your AWS account, every action requires your explicit approval. You see what the platform proposes, review the cost and impact, and approve or reject.

As the platform builds a track record of successful, safe operations, it earns autonomy:

• Low trust (new accounts): Every action requires human approval.
• Medium trust: Routine, low-risk operations (scaling replicas, extending storage) proceed autonomously. Higher-risk operations still require approval.
• High trust: Most operations proceed autonomously. Security group changes and IAM modifications still require approval.
• Destructive actions: Always require human confirmation. Teardowns, deletions, and destructive operations never become autonomous, regardless of trust score.

Trust decays over time. If the platform isn't used, the score decreases and operations that were previously autonomous require re-approval.

Your Data and Access

Your infrastructure stays in your AWS account. Edict Labs is a control plane, not a hosting provider. Your resources, your data, and your configurations live in your account. If you disconnect Edict Labs, your infrastructure continues running exactly as it was.

Read-only by default. When you first connect an account, the platform operates in read-only mode. It discovers what's running, shows you costs and configurations, and identifies drift. No action is taken until you explicitly grant provisioning access.

You control the scope. You decide which AWS accounts, regions, and resource types the platform can manage. Access can be narrowed or revoked at any time.

Compliance Readiness

The architecture produces audit-ready evidence out of the box.

SOC 2 Type II:

• Change management (CC8): every change records who requested, what was proposed, what policy checks ran, what was approved, and what was executed.
• Access control (CC6): credential issuance, scope, duration, and revocation are logged for every operation.
• Monitoring (CC7): drift detection runs continuously with alerting on unauthorized changes.

HIPAA:

• All infrastructure actions logged with full context.
• Access scoped and time-bound by default.
• Audit trail is tamper-evident.

Summary

Questions

Questions about our security model? Need something specific for your security review? Reach out at hello@edictlabs.ai.