Marshal
What it coversHow it worksSampleBill scanPricingTrustStart freeSign in
Read-only by default. Approval-gated always.

What Marshal can touch, said plainly.

Read this before you click "Create stack". Written for the person who signs off, not for a lawyer. Every claim describes what the product does today.

  1. Read role

    Describe, list and get. Cannot change anything.

  2. Marshal reads

    Billing, resources, security settings, uptime.

  3. Draft

    One allowlisted fix, undo stated plainly.

  4. You approve

    Or you never install the fix role at all.

    Waiting for you

  5. Fix role acts

    Only that action, only those permissions, logged.

  6. Revoke

    Delete the stack. Access ends at once.

How access works

Read-only first. Fixes need a second role you choose to install.

The read role, installed first

  • Connecting AWS creates one role in your own account, MarshalReadRole, through a CloudFormation stack you can read line by line before you run it.
  • It can only be assumed with a secret External ID unique to your organization, so a leaked role name is not access.
  • Its permissions are describe, list and get on metadata. It cannot create, modify, or delete anything in your account.
  • Delete the stack whenever you like and our access ends instantly.

The fix role, only if you want fixes

  • One-click fixes need a second, separate role: MarshalRemediateRole. Never installing it is a supported way to use Marshal.
  • Its permissions mirror the action catalog exactly, nothing wider. The code asserts at startup that every action has a reviewed implementation and a matching, narrow permission.
  • An action that is not in that catalog cannot be proposed, approved, or executed. The guardrail lives in code and in IAM, never in a prompt.
  • You can switch off any category of action permanently in settings.

How credentials are handled

The default path means we never hold a key of yours.

Role, not keys

The default connection is a cross-account role plus a unique External ID. There are no long-lived AWS credentials for us to hold, rotate, or lose.

Encrypted at rest

If you paste access keys instead - the interface says why you should not - they are encrypted at rest before they are stored. Same for Datadog and Sentry tokens.

Never handed back

No API returns a stored secret, to anyone, including you. Webhook URLs are shown with the host only, and a failed delivery logs the type of error, never the address.

Google Cloud stores nothing secret

A Google Cloud connection keeps only the project and billing table identifiers.

Kubernetes never hands over a key

The cluster agent is read-only, runs inside your cluster, and pushes metrics out. We get no credentials to your cluster at all.

It refuses to run unconfigured

In production Marshal refuses a default signing secret. The credential encryption key is also required: connection setup fails loudly before a secret can be stored if the deploy omitted it.

What we read, and what we never read

Bills and settings. Not your customers' data.

What Marshal reads

  • Your billing export, from the S3 bucket the setup creates in your own account
  • Cost and pricing APIs, to price a fix at the rate you actually pay
  • The list of your resources: servers, disks, databases, load balancers, clusters
  • Utilization metrics such as CPU and network, to judge what is oversized
  • Account-level security settings: root MFA, audit logging, default disk encryption, public-access blocks

What it never reads

  • The contents of your storage buckets - the read role can fetch objects from the billing export bucket only
  • Rows in your databases - Marshal reads a table's settings, never the data inside it
  • Your application traffic, logs, or customer records
  • Anything at all in write mode, until you install the separate fix role and approve a specific action

This is not a policy promise, it is what the permissions allow. The CloudFormation template lists every single permission it grants, and you read it before you install it.

The approval gate

Propose, approve, execute. In that order, every time.

app.marshalcloud.com/operations/fixes
Marshal

Today

  • Dashboard
  • Executive brief
  • Ask Marshal
  • Quickstart
  • Automations

Marshal Team

  • FinOps
  • SecOps
  • DevOps
  • Compliance
  • Architect

Money

  • Spend
  • Explore costs
  • Unusual spending
  • Savings7
  • Commitments
  • Budgets
  • Cost ownership
  • Unit economics
  • AI credit
  • Bill scan

Risk & resilience

  • Reliability
  • Security2
  • Risk breakdown
  • Vulnerabilities
  • Fraud & abuse
  • Workload scans
  • Who can access what
  • Threat map
  • Spotlights
  • Audit readiness
  • Alerts3
  • Backups

Operations

  • Monitoring
  • Fix executions1

Build

  • Environments
  • Blueprints
  • Change requests
  • Deploys

Infrastructure

  • Cloud estate
  • Architecture
  • Changes
  • Kubernetes
  • Devices

People & response

  • War room
  • On call
  • Incident reviews
  • Team

Workspace

  • Settings
  • Analyst skills
Awaiting your approvalexample

Stop staging-worker-03

No application connection or customer dependency was observed. The disks survive and the instance can be started again. The open security group remains a separate finding.

Approve fixNot now

This is the whole gate: Marshal writes the plan, a person presses the button. There is no path around it.

1

Propose

Marshal drafts the exact change, in plain language, with the dollar impact priced from your own bill and one sentence saying whether it can be undone. Then it stops.

2

Approve

A person with approval rights approves that specific action. Who proposed it and who approved it are both recorded. Fully automatic mode is refused by the API, not merely discouraged.

3

Execute

Marshal re-checks live state before touching anything and records every step. Each plan states whether it is reversible, can only recreate an equivalent from a snapshot, or is irreversible before approval.

Every action carries its own undo story

The label comes from what the code can actually roll back, not from how safe an action feels. The matching sentence is appended to the plan you approve, so nobody ever approves without knowing which of these three it is.

Reversible
You can undo this with one click.
A rollback is registered and restores the same resource: stopping a server, changing a disk type, resizing an instance.
Compensating
Undo recreates an equivalent - the original is gone.
Deleting an unattached disk restores from the safety snapshot, so you get a new disk with the same data, and only while the 14-day snapshot lives.
Irreversible
This cannot be undone.
Releasing an IP address, deleting a backup, or buying a savings plan spends something Marshal cannot put back. These sit behind an extra confirmation.

Data handling

What we keep, and how it goes away.

What we store

  • Billing lines from your cost export, so we can price things against what you actually paid.
  • Inventory metadata: the resources you run, their configuration, and how they connect to each other.
  • Results of the checks we run for you: uptime and certificate checks, security posture findings, budgets and alerts.
  • Every organization's data is stored and queried per tenant, and each fetch by ID is checked against the caller's organization in one shared place, so a new page cannot forget the check.

How it goes away

  • Disconnect a cloud account, or delete the CloudFormation stack in your own account, and our access to it ends immediately.
  • Ask us to delete your organization and we erase it: the records in our database and your billing rows in our warehouse, along with cached copies.
  • The deletion reports back whether each of those stores was actually cleared, so nobody assumes erasure finished when half of it did.
  • Deleting an organization is irreversible, so it takes an exact-name confirmation to run.

AI boundaries

The analyst can investigate and prepare. It cannot approve or execute.

Marshal's analyst answers questions about your own data. Its evidence tools are read-only. For an authorized approver it can also create a proposal record from the reviewed action catalog. It cannot approve that proposal or execute infrastructure changes; those gates live outside the model.

  • No approval or execution tools, structurally. The model may prepare an allowlisted proposal for an authorized user, but it cannot approve it or execute a cloud change. A person controls both gates.
  • Tool results are data, never instructions. Text pulled from your cloud is encoded, length-capped, and stripped of control characters, and a standing rule tells the model that such text is data. The guardrails live outside the model, not inside a prompt.
  • Playbooks are allowlisted. The investigation playbooks the analyst can follow are a fixed list in our repository, chosen by name from an allowlist.
  • Capped by organization. Each organization has a daily token budget. Past it, the endpoint declines rather than running up a bill.

Still on our list

The things we have not finished yet.

A trust page that only lists wins is not a trust page. We keep a written security analysis with the open items in it, and we would rather you heard them from us: encryption of stored credentials is moving from our current scheme to a managed-key envelope before general availability, session tokens are moving out of browser storage, and the formal SOC 2 work - retention, access reviews, an incident runbook, a penetration test - is in progress, not done. The technical controls described above are built today.

If you are evaluating Marshal for a security review, write to us and we will walk your team through the analysis line by line.

Found something? Tell us.

Report a vulnerability to hello@marshalcloud.com. Include what you found and how to reproduce it. We will confirm we received it, keep you updated while we fix it, and we will not come after anyone who reports in good faith.

Report a vulnerability
See pricing

Marshal

Marshal is a cloud cost, security and uptime platform for teams without a separate FinOps, security or SRE function. It reads AWS, Google Cloud and Kubernetes, names what changed, and drafts the fix. A person approves every change.

Free for one AWS account. Paid plans from $125 a month, 15 days free.

hello@marshalcloud.com

Product

  • What it covers
  • How it works
  • Sample brief
  • Free bill scan
  • Pricing

Trust

  • Security and access
  • How credentials are handled
  • Subprocessors
  • Report a security issue

Legal

  • Terms
  • Privacy
  • Data processing

Your cloud, handled. One approval at a time.

Read-only to connect. Nothing changes without your approval.