AWS and Cloudanix team co-authored this blog: Real-Time Threat and Anomaly Detection for Workloads on AWS
Coding Agent JIT · powered by Cloudanix Agentic JIT

Give Claude the job.
Not the keys.

Your developers now hand real tasks to Claude Code, Kiro, Cursor and Codex — “fix that S3 bucket,” “query the prod DB,” “add a user to Sendgrid.” Coding Agent JIT is how you let them do it safely: short-lived credentials over MCP, optional human approval, complete audit, automatic revoke.

✓ Works with any MCP agent ✓ AWS · Azure · GCP · DBs · SaaS ✓ SOC 2 · HIPAA · ISO 27001
code — ✶ Claude Code — claude — 210×58
Claude Code v2.1.131
Welcome back Sujay!
Opus 4.7 (1M context) with me… · Claude Max
● I'll need temporary AWS access on prod-logs. Invoking cloudanix-jit MCP…
tool: cloudanix-jit.request_access 
{
  "resource": "arn:aws:s3:::prod-logs",
  "actions":  ["s3:PutBucketPolicy"],
  "reason":   "Enforce aws:SecureTransport=true",
  "duration": "15m"
}
$ aws s3api put-bucket-policy --bucket prod-logs --policy file://deny-insecure.json
✓ Bucket policy applied. HTTPS-only now enforced.
● Task complete. Releasing credentials.
The problem

Today, giving an agent access means giving it your keys.

Agents like Claude can execute real work — but every path to letting them do it ends in a long-lived secret living somewhere it shouldn't.

🔑

Long-lived keys in dotfiles

AWS access keys, DB connection strings and SaaS admin tokens end up in ~/.aws, .env and MCP server configs. The blast radius is the full lifetime of that key — not the 47 seconds the agent actually needed.

👻

Unaudited agent actions

When Claude runs under a shared service account, CloudTrail and DB logs all read “svc-deploy”. You can't tell which human asked, which agent acted, or why. Approvals, reviews, forensics — all blind.

🛑

No way to say “no”

Read a prod table? Drop a Sendgrid list? Rotate a KMS key? Today the only controls are “has the key or doesn't.” There is no tiered approval, no intent-scoped grant, no policy that understands an agent is asking on behalf of a human.

How it works

A broker between the agent and the system of record.

The Cloudanix JIT MCP server is the only thing the agent ever sees. It mints, scopes, and destroys credentials on your behalf.

  1. 1

    Agent makes an intent call

    Over MCP: “I want to do X on Y for reason Z, for N minutes.” The agent never sees a credential.

  2. 2

    Cloudanix evaluates policy

    Scope, blast radius, environment, identity of the human, history of the agent. Most read intents auto-approve; risky writes escalate.

  3. 3

    Human-in-the-loop (when it matters)

    Slack / Teams / email approval with full context. Approve once, for this intent only. No silent re-use.

  4. 4

    Short-lived credentials issued

    Scoped to the exact action, resource and TTL. STS on AWS, brokered session on DBs, minted-and-revoked API keys on SaaS.

  5. 5

    Revoke & write the audit record

    Credentials destroyed the moment work ends or TTL expires. Every hop — intent, approval, execution — linked to a real human identity.

Real-world scenarios

Same JIT. Any target your agent needs to touch.

Databases, SaaS admin APIs, internal MCP endpoints, cloud control planes — anywhere a human would need a key, Cloudanix brokers it for the agent instead.

scenario · prod-db · PostgreSQL
sujay “Query the users table — I need the address for id = 10 for support ticket CX-4821.”
Claude
✶
request
Cloudanix JIT
◎
session
prod-db
🗄
scope granted SELECT · public.users · 5m · read-only replica 
psql> SELECT address FROM users WHERE id = 10;
 address
-----------------------------------------
 221B Baker Street, London
(1 row)
✓ 1 row returned ⛔ Session closed · 00:03s
scenario · Sendgrid · SaaS admin API
sujay “Add new@example.com to the Launch Waitlist list — please don't ask me for the admin key.”
Claude
✶
request
Cloudanix JIT
◎
minted key
Sendgrid
✉️
scope granted contacts:create · lists.launch-waitlist:append · 2m 
POST /v3/marketing/contacts
{"list_ids": ["launch-waitlist"],
 "contacts": [{"email": "new@example.com"}]}
→ 201 Created
✓ Contact added ⛔ Minted key destroyed · 00:02s
scenario · Stripe · restricted key rotation
sujay “Rotate the restricted Stripe key used by billing-worker. The old one was posted in a GitHub PR.”
⚠ write · prod · irreversible → ✓ Approved by alice · 2s
Claude
✶
request
Cloudanix JIT
◎
token
Stripe
💳
scope granted api_keys:create · api_keys:revoke · account=acct_live · 10m 
POST /v1/api_keys  (restricted, scoped to billing-worker)
→ new key: rk_live_•••••RM9w
POST /v1/api_keys/rk_live_•••••prevQ/revoke
→ old key: revoked
✓ Key rotated · new key written to Vault ⛔ Broker token destroyed · 00:08s
scenario · EKS · node patching
sujay “Drain node ip-10-0-42-17 on prod-eks so platform can patch the kernel.”
Claude
✶
request
Cloudanix JIT
◎
kubeconfig
prod-eks
⎈
scope granted nodes:cordon · nodes:drain · node=ip-10-0-42-17 · 15m 
$ kubectl cordon   ip-10-0-42-17
node/ip-10-0-42-17 cordoned
$ kubectl drain    ip-10-0-42-17 --ignore-daemonsets
evicting pod/checkout-svc-7d4-x8qz
evicting pod/payments-api-6f2-lt9n
node/ip-10-0-42-17 drained
✓ 14 pods evicted · node ready for patching ⛔ kubeconfig destroyed · 00:47s
works the same for Snowflake GitHub Slack PagerDuty Terraform Cloud Datadog Okta MongoDB …and any MCP endpoint
The model

The agent sees an intent. The org keeps the keys.

What the agent sees
  • An MCP tool it can call with an intent
  • A response: “granted” or “denied, because…”
  • A session-scoped handle for exactly the declared action
  • Nothing that survives the task
cloudanix-jit.request_access(intent)
What you keep
  • The real AWS / DB / SaaS credentials — never leave your vault
  • The policy that decides what each agent is allowed to request
  • The approval workflow that gates risky writes
  • The immutable audit trail tying every action to a human
Governance lives here.
Agent-native

If it speaks MCP, it works.

Not bound to a vendor, a protocol variant, or a single agent. Point any MCP client at the Cloudanix JIT server and your developers get keyless access the same day.

Claude Code
Kiro
Cursor
Codex
Any MCP client
What you get

Governance an agent can't route around.

⏱

Short-lived, intent-scoped

TTL-bound credentials tied to a specific action, resource and reason — never a broad role.

✋

Tiered human approval

Auto-approve read intents. Escalate writes on prod to Slack. Tune blast-radius thresholds per team.

📜

Immutable audit

Every intent, approval and action tied to a real human identity. CloudTrail and DB logs, correlated.

🧨

Automatic revoke

TTL expiry + explicit release + idle revoke. Zombie credentials can't outlive the task.

🎯

Works on SaaS too

Not just AWS STS. Mint-and-revoke flows for Sendgrid, Stripe, Snowflake, Postgres, and more.

🧩

One JIT for humans & agents

Same policy engine, same approval flows, same audit — whether the actor is a person or an LLM.

Ready to see your graph?

Connect a cloud account in under 30 minutes. See every finding rooted in identity, asset, and blast radius — with a fix path attached.

Book a Demo