← Use cases

Cloud Platform / IAM

Agents that act on AWS

An agent writes to DynamoDB, drops files in S3, or triggers Lambda — today that usually means a long-lived IAM access key sitting in the agent’s environment.

Real example — shipping today

source →

AWS · IAM roles & STS temporary credentials

AWS STS can mint short-lived, scoped credentials on demand instead of a standing access key — the primitive MCPIP’s cloud broker vends per call so the agent never holds a durable secret.

The danger without a gate

A standing key is the crown jewels: broad by convenience, valid around the clock, and one prompt injection (or one leaked env var) away from being used for anything it permits — with CloudTrail only telling you afterwards.

How MCPIP handles it, step by step

Read it top to bottom. Each step shows the real command and exactly what MCPIP returns — the same allow / step-up / denied envelope every time.

1

The agent asks to write — holding no AWS key at all

It requests a DynamoDB write through MCPIP. There is no standing credential anywhere in the agent’s environment. A write is high-risk, so MCPIP stages a PIN.

bash
$ mcpip --json authorize skill_dynamodb_write --arg item_id=ord-9912 \
  --credential-out /tmp/cred.json
step-up requiredwhat mcpip returns
{
  "error": "step_up_pending",
  "challenge_id": "chg_4e21aa",
  "correlation_id": "a19be0c4"
}
2

On approval, MCPIP vends a scoped, short-lived credential

After the PIN, MCPIP seals the record and vends an STS credential scoped to PutItem on one table. It’s written to a 0600 file — never stdout, never a log, never the WORM record.

bash
$ mcpip --json complete --challenge chg_4e21aa --credential-out /tmp/cred.json
allowwhat mcpip returns
{
  "decision": "allow",
  "status": "executed",
  "transaction_ref": "txn_c4d5e6",
  "executed_target_class": "cloud_iam",
  "worm_sequence": 48221,
  "correlation_id": "a19be0c4",
  "vended_credential": { "redacted": true, "written_to": "/tmp/cred.json" }
}
3

The credential can do nothing else, and expires on its own

Even if it leaked, it can only PutItem on that one table, for minutes. There’s no crown-jewels key to steal. The same ceremony covers GCP and Azure.

The result

Cloud actions with least-privilege minted per call — no standing credential to steal.

scoped STS vendpayload PINopaque aliasno standing key

The same flow, at a glance

AGENTMCPIPAWS STSDYNAMODBauthorize writeno AWS key in the agentstage · pin_requiredcomplete · PINverify · seal WORMvend scoped credentialPutItem · one tablewrite with vended cred

Every command above runs against a local sandbox in one line.

run it yourself — curl … | bash && mcpip up →