Trust

Permissions, dry-run, and audit trail.

Giving an agent permission to change production is a trust motion. Mendhelm earns it by making the controls explicit — what each scope grants, what dry-run mode blocks, what the audit trail records — and by naming the things the agent will never touch.

least-privilege by default
dry-run on for any write
immutable audit trail

Section 01 · Layered permissions

One IAM principal per environment per service.

Mendhelm does not share a single assume-role across your whole account. We register one role per environment (dev / stg / prod), one per cloud (AWS / GCP / Azure / Kubernetes), and one trust boundary per service. Every action traverses that chain — so revoking a layer immediately shrinks what the agent can do, and audit logs carry the full path from the org down to the resource.

LayerReadWrite
org

List accounts / projects / subs / clusters

— none —

environment (dev / stg / prod)

Resource inventory, IAM policy state, drift deltas

Bound by env tag — prod writes only on explicit allow

service boundary

Pods / ECS tasks / functions / VM instances

Restart, replace, scale within service namespace

resource group / namespace

K8s objects inside the namespace

Patch, restart, roll — never delete the namespace

Read vs write

Read scopes are wide-open by intent — drift detection is no good if it can't see the resource. Write scopes are narrow by design. The first thing you grant on day one is read; writes unlock per-action-class as you sign off on each one.

  • Read scopes are account-wide and resource-wide by default.
  • Write scopes always come with a paired dry-run envelope first.
  • Production writes require an explicit allow flag — never inferred from the namespace.

Section 02 · Least-privilege scoping

The blast radius is exactly what you grant — never a quote wider.

Onboarding hands Mendhelm the narrowest scopes that drift detection and healing still work under. We scale up only as you sign off on each new action class. These invariants run for every environment you connect.

  1. invariant · 01

    Read is the floor, write is opt-in.

    Every new environment ships with read-only scopes. Write actions unlock one at a time, per action-class, after a human signs off on the dry-run shape.

  2. invariant · 02

    One principal, one purpose.

    There is no shared assume-role. Each role has a single intended purpose (drift detection, healing, patching) annotated in its name and description — so an audit trail reads as intent, not just action.

  3. invariant · 03

    Resources carry a sticky owner.

    Scopes inherit from tags and labels, not from the IAM chain alone. Tag drift is itself drift — and gets reported, never silently relied on.

  4. invariant · 04

    Permissions rotate weekly, not never.

    Service-account keys, assume-role sessions, webhook signing secrets, and K8s service-account tokens rotate on a fixed cadence. Old keys are revoked on day seven.

  5. invariant · 05

    Wildcards require two humans.

    Any `iam:*`, `secretsmanager:*`, `cluster-admin`, or wildcard binding added to a scope triggers a second reviewer — the agent refuses to operate under it until a signed-off manifest lands.

Section 03 · Dry-run mode

Default ON. Toggle OFF for direct execution.

Every write action ships as a dry-run envelope first: identical intent, identical scope, no mutation. The agent generates the diff, attaches it to an audit record, and waits for either an automatic promotion (after your N-second policy) or a human sign-off. Toggle dry-run OFF per action-class when you want direct execution — the toggle is sticky and the audit trail records every flip.

The toggle is a property of the action class, not the operator. Changing it does not require redeploying Mendhelm.

Toggle states · per action class
dry_run · on
default

Diff first, record the intent, promote after policy window or human ok.

dry_run · off
permissive

Direct execution. Audit trail still records prompt, scope, and outcome.

change_window · freeze
hard block

Honored verbatim. Mendhelm refuses to mutate, regardless of the dry-run toggle.

Section 04 · Audit trail

Append-only. Tamper-evident. Yours forever.

Mendhelm does not own your audit trail — it streams every action to your destination (CloudTrail, GCP Audit Logs, Azure Activity, Kubernetes audit log, plus a Mendhelm activity feed) and to the digest. Rolling audit history forward is a read operation, never a write.

What we record per action
prompt

The full agent prompt that produced the action, hashed and stored.

scope

Exact principal, role, and resource ARN / namespace at action time.

intended_diff

The structured diff the agent proposed, before execution.

actual_diff

The diff that landed. Intent vs. actual surfaces honest mismatches.

dry_run

Boolean: was this promoted from dry-run, executed directly, or blocked?

outcome

Success, partial, rolled back, promoted, escalated — with reason codes.

Who can read

The audit stream is readable by your security, your SRE leads, your auditor, and Mendhelm on-call — at read-only scopes. No one holds a write scope on the trail.

  • Mendhelm never deletes records. Only retention rules at YOUR storage layer govern deletion.
  • The trail is the artifact for the weekly digest. Each row links to its signed audit entry.

Section 05 · Concrete scopes

What the manifest actually looks like.

Two worked examples — staging on AWS, and a single namespace on Kubernetes — of the exact permissions Mendhelm asks for and the exact things it refuses to do inside that scope.

example · AWS · stg
dry-run default

Scope

iam:AssumeRole → mendhelm-stg-read / mendhelm-stg-write

Mendhelm will

  • · Diff assume-role policies against the last approved manifest.
  • · Restart ECS services tagged env:stg.
  • · Rotate Lambda function env vars on pinned secrets.
  • · Open a ticket if a write scope is missing rather than escalate it.

Mendhelm won't

  • · Call iam:DeletePolicy on any resource.
  • · Touch secrets manager entries outside the explicit allow tag.
  • · Cross into another account (aws:ResourceAccount denied).
  • · Modify billing, support plans, or AWS Organizations.
example · Kubernetes · prod/ns
dry-run default

Scope

ServiceAccount · mendhelm · namespace: checkout-prod

Mendhelm will

  • · Roll Deployments and StatefulSets in place.
  • · Restart pods on stuck CrashLoopBackOff.
  • · Patch HPA / PDB templates within the namespace.
  • · Server-side dry-run every patch before applying it.

Mendhelm won't

  • · Bind cluster-admin, admin, or wildcard verbs.
  • · Create or delete namespaces, CRDs, or ClusterRoles.
  • · Read secrets outside the namespace's allow-listed selector.
  • · Apply changes outside change windows or freeze periods.

Section 06 · Contrast

What the agent never touches.

The inverse of the scope is the contrast: an explicit negative list. If a thing is on this list, the agent fails closed — even if you accidentally grant a wildcard — because the policy lives at our end too, not only yours.

Never touchesWhy
production secrets

Secrets manager entries tagged restricted, K8s secrets with allow-listed selectors, and any secret newer than the last human-approved rotation window.

IAM policy deletion

iam:DeletePolicy, iam:DetachUserPolicy, and any wildcard (*) grant require explicit human approval — Mendhelm rejects them at the scope check.

billing mutators

No write scope to AWS Billing, GCP Billing, Azure Cost Management, or any Stripe / vendor billing API. Reads are limited to anomaly detection.

destructive data ops

No DROP, TRUNCATE, or DELETE on databases unless a separate data-class scope is granted. Default posture is append-only on applied diffs.

support / org administration

AWS Support plans, Organizations SCP writes, Azure subscription moves, and GCP project IAM for org-level admins are out of scope by default.

auditor data deletion

Audit streams are append-only at the storage layer. Mendhelm never holds a delete scope on CloudTrail, GCP Audit Logs, or Kubernetes audit log sinks.

Getting started

Read the manifest. Book a 30-minute scope review.

We take the first call personally. Walk us through your AWS / GCP / Azure / Kubernetes surface, and we'll return a minimal scope manifest you can diff against what you already run — and what the platform itself has been doing for the last 90 days.

Talk to the founderSee platform status →Back to overviewJoin the waitlist

response within 24h · no automation · founder-led scope review