Disclaimer: Use of Lowkey (Loki) Agent

1. Not an Amazon Product

Lowkey (also referred to as "Loki") is an open-source, third-party project. It is not an Amazon or AWS product, is not developed, maintained, endorsed, warranted, or supported by Amazon, and carries no AWS service-level agreement. We are sharing it because we believe it may be useful to customers who want to prototype rapidly on AWS — nothing more.

Project references:

• Source: github.com/inceptionstack/lowkey
• Website: lowkey.run

Your use of Lowkey is governed solely by the licenses and terms published by the Lowkey project.

2. What Lowkey Does (and Risks Involved if Not Managed Properly)

Lowkey is an autonomous AI agent that runs inside your AWS account and can design, deploy, modify, and delete AWS resources on your behalf. Lowkey ships with administrator privileges out of the box, which you can and should adjust to fit your needs and your organization's risk posture.

LLMs can make mistakes. That reality applies to every LLM-powered system, and Lowkey is no exception. Because Lowkey is built in part on OpenClaw, it inherits OpenClaw's underlying behavior — and the scope of any mistake scales directly with the scope of the permissions and data you give the agent.

Managed well, Lowkey is a fast, capable builder. Managed poorly, Lowkey (by way of OpenClaw) has the potential — for example — to:

• Misconfigure IAM policies or create overly permissive security groups
• Create, modify, or delete AWS resources in ways you did not intend
• Generate unexpected cost by provisioning or leaving infrastructure running
• Produce non-deterministic or incorrect output typical of LLM-driven automation
• Expose data the agent has been granted access to

None of these are reasons to avoid Lowkey. They are reasons to scope its permissions, isolate its environment, and monitor what it does — which the rest of this document describes in detail.

3. Recommended Practices Before You Run Lowkey

If you choose to evaluate Lowkey, we strongly recommend — at a minimum — that you follow all of the practices below.

3.1 Skilled Operator: Operate Lowkey with a skilled operator from day one

The single biggest factor in whether a Lowkey prototype is more secure, spends less money, and is well architected and can later be graduated to production is who is sitting at the keyboard. We strongly recommend that Lowkey be operated, from the very first session, by a skilled operator — an architect or senior technical person with working knowledge of:

• The AWS Well-Architected Framework (operational excellence, security, reliability, performance, cost, sustainability)
• IAM, networking, and AWS security services
• Software engineering practices: code review, testing, modularity, secrets management
• Infrastructure-as-Code patterns and CI/CD design

A skilled operator will steer the agent toward designs that are already close to production-grade, catch unsafe patterns early, and make the eventual graduation a review — not a rewrite. Lowkey amplifies the person driving it: a strong operator produces prototypes that could graduate; a weak operator produces prototypes that cannot.

3.2 Use a dedicated sandbox AWS account under AWS Organizations

• Create a dedicated sandbox account inside your AWS Organization specifically for Lowkey.
• Apply Service Control Policies (SCPs) to restrict the blast radius (e.g., deny production regions, deny IAM changes outside the account, deny access to shared resources).
• Never install Lowkey in a production account, a shared services account, or any account that contains data, credentials, or workloads you are not prepared to lose.

3.3 Put nothing in the account you are not willing to lose

• LLMs make mistakes. A lot.
• Assume every resource in the sandbox account can be deleted, modified, or exposed by mistake at any time.
• Do not place production data, customer data, long-lived secrets, or irreplaceable artifacts in the account.
• Treat the account as ephemeral.
• Save all code to a code repository continuously.

3.4 Monitor and control cost aggressively

Lowkey can provision real, billable AWS infrastructure. Before you start:

• Configure AWS Budgets with a hard monthly cap appropriate to your prototype(s).
• Configure budget alerts at meaningful thresholds (e.g., 50%, 80%, 100%).
• Configure AWS Budget Actions to automatically apply restrictive IAM policies or stop resources when thresholds are breached.
• Enable AWS Cost Anomaly Detection on the account.
• Review the Cost Explorer daily while the agent is active.

3.5 Estimate cost before you build

The cheapest way to control cost is to decide what you are willing to spend before the agent provisions anything. Make cost part of the design conversation, not a post-mortem.

Chat with Lowkey about costs:

• Before asking Lowkey to deploy or build anything non-trivial, ask it to produce an estimated monthly cost for the proposed design.
• Ask Lowkey for alternative designs at different price points (e.g., serverless vs. always-on, single-AZ vs. multi-AZ, managed service vs. self-hosted) and weigh the trade-offs explicitly.
• Require the agent to flag any component likely to dominate the bill (NAT gateways, cross-AZ traffic, idle compute, always-on databases, premium tiers).

Re-estimate whenever the design materially changes. Treat the estimate as an artifact worth saving in the repository alongside the code.

3.6 Have Lowkey produce daily status briefings

Configure Lowkey to generate a daily briefing covering every prototype it is managing, so nothing drifts out of sight. A good daily briefing includes:

• Cost: yesterday's spend, month-to-date spend, and any spikes or anomalies versus the prior day.
• Security: new GuardDuty / Security Hub findings, IAM changes, public-exposure changes, unusual API activity.
• Application state: health of each prototype, latest deploy status, failing checks, open incidents, resources that look idle or abandoned.

The Lowkey project provides Bootstrap markdown files that make this easy to wire up. See the official essential bootstraps for reference:

• github.com/inceptionstack/lowkey/tree/main/bootstraps/essential

Route the briefing to wherever the skilled operator actually reads messages (Slack, Telegram, Discord, email) and read it every day while any prototype is live.

3.7 Scope for prototyping first

Out of the box, Lowkey is appropriate for very fast prototyping and experimentation. As shipped, it is not appropriate for:

• Production workloads
• Regulated data (PII, PHI, PCI, etc.)
• Any environment where uptime, auditability, or compliance matter — unless you follow the graduation path in Section 4.

4. Graduating a Lowkey Prototype to Production

There is a viable path from a Lowkey prototype to a production workload, provided the following practices are observed. Treat these as required, not optional.

4.1 Everything lives in a code repository

• Every prototype must exist as code in a repository from the start — not just as live AWS resources.
• Prefer internal, in-account source control (for example, AWS CodeCommit, or your organization's internal Git host) so prototype code does not leak into external Git organizations unless you explicitly want it to.
• Commit early and often so that the repository — not the AWS account — is the source of truth.

4.2 Keep the CI/CD footprint internal while prototyping

While prototyping, we recommend using AWS-native, in-account CI/CD services such as CodeCommit, CodeBuild, CodePipeline, and CodeArtifact. This keeps early experiments out of external SaaS organizations and makes it easy to tear everything down with the sandbox account.

4.3 Generate reviewable & executable Infrastructure-as-Code artifacts

A prototype is not graduation-ready until the infrastructure is expressed as reviewable and executable IaC:

• Emit Terraform or AWS CloudFormation / CDK artifacts for all provisioned resources.
• No production resource should be created by the agent directly — it should be created by IaC that a human approved.
• Keep IaC, application code, and pipeline definitions in the same repository so they are reviewed together.

4.4 Mandatory architect review before graduation

Before any Lowkey-originated workload graduates to a production account, we recommend it pass a formal review by an architect (or equivalent senior technical reviewer) covering at minimum:

• Well-Architected review across all six pillars
• Security review: IAM least-privilege, secrets handling, data protection, logging, network exposure
• Code review: correctness, maintainability, test coverage, error handling
• Cost review: steady-state cost, scaling behavior, cleanup paths
• Operational review: observability, runbooks, failure modes, rollback

4.5 Graduate into a different account

• Graduation normally means redeploying the reviewed IaC into a separate, non-sandbox AWS account (ideally through your standard landing-zone / Control Tower process). The sandbox account remains the sandbox; do not promote it.
• Alternatively, you may opt to remove Lowkey from the account entirely and then treat the account as a production account.
• Alternatively, you may opt to keep Lowkey in the account but downgrade its IAM permissions to read-only, and use it as your daily monitoring assistant rather than a builder.

Prototypes operated this way — by a skilled operator, captured as IaC in a repository, reviewed by an architect, and redeployed into a proper production account — can legitimately become production workloads. Prototypes operated any other way should be treated as throwaway.

5. Your Responsibility

6. With Great Power Comes Great Responsibility

Builder, Fullstack Agents with powerful access are a genuinely new class of tool. Used inside a tight sandbox, with budgets and guardrails, Lowkey can compress days of prototyping into minutes. Used carelessly, it can produce a very expensive, very public mistake in the same amount of time.

Please choose the first option.