TryAudex

Scoped, short-lived cloud credentials for AI coding agents. Stop giving your agent full cloud access.

Tip

Multi-cloud (AWS / GCP / Azure / Vault), auto-revoked after each command, append-only audit trail.
Built for the age when your agent has a rm -rf / prompt-injection away from production.

	Follow @Aditya-PS-05 on GitHub for more projects. Hacking on AI infrastructure, cloud security, and everything in between.

Run cargo install tryaudex and wrap your next aws, gcloud, or terraform command — your agent will thank you when it can't delete the bucket.

Overview	Sessions

Audit Trail

Launch the interactive dashboard with tryaudex dashboard — see active sessions, per-service usage, and the full HMAC-signed audit trail in real time.

Overview

Audex gives AI agents (Claude Code, Cursor, Windsurf, Codex CLI, and friends) scoped, short-lived cloud credentials — one command at a time. Instead of handing your agent a long-lived IAM user or service account key, you wrap every command:

Provider	Backend	Max TTL	Supported
AWS	STS AssumeRole + inline session policy	12h	✅ Yes
GCP	Service account impersonation via IAM Credentials API	1h	✅ Yes
Azure	Azure CLI credentials + scoped RBAC role assignments	1h	✅ Yes
HashiCorp Vault	AWS secrets engine (Token / AppRole / Kubernetes auth)	Role-defined	✅ Yes

Audex issues temporary credentials valid only for the actions you listed, injects them into the subprocess, and logs the session to an append-only audit trail signed with an HMAC chain. When the command exits (or the TTL expires), the credentials stop working.

Why "Audex"?

The name is audit + exec. Every cloud call your agent makes is wrapped, scoped, and logged — you get the convenience of letting an AI do real work, with the paper trail of a compliance tool.

In the age of AI-assisted development, credentials are the new attack surface. A single AWS_ACCESS_KEY_ID sitting in a dotfile is one prompt injection away from becoming a DeleteBucket call. The traditional fixes — manual IAM scoping, long-lived keys in vaults, "just give it admin for now" — don't scale when the thing calling your API is a non-deterministic language model that can be socially engineered by a README.

Audex shrinks the blast radius to exactly what each command needs, for exactly as long as it needs it. Think of it as a Kardashev scale for credential scope: from Type I (full account access) down to Type III (a single action, on a single resource, for 90 seconds). Climb down the scale, one tryaudex run at a time.

Contents

• Overview
  • Why "Audex"?
• Features
• Installation
  • Quick Start
  • Prerequisites
  • From Source
• Usage
  • Basic Commands
  • AWS
  • GCP
  • Azure
  • HashiCorp Vault
  • Built-in Profiles
  • Sessions & Audit
  • Interactive Dashboard
  • Natural Language Policies
  • Policy Learning from CloudTrail
  • Multi-Account Support
  • Approval Workflows
  • Chained Commands
  • Configuration
  • Environment Variables
• MCP Integration
• Team Mode (Server)
• How It Works
• Security Model
• Documentation
• Development
  • Prerequisites
  • How to Run
• Supported Platforms
• CLI Reference
• Contributing
• Acknowledgments
• License

Features

• Multi-Cloud — Unified policy syntax across AWS, GCP, Azure, and HashiCorp Vault. Same --allow flag, four credential backends.
• Scoped Credentials — Inline session policies restrict each command to exactly the actions you list. No accumulated permissions, no leaking scope across runs.
• Short-Lived by Default — TTL enforced by the cloud provider (max 12h AWS, 1h GCP / Azure). Default 15 minutes, override per-command.
• Append-Only Audit Trail — JSONL log with HMAC-SHA256 chain for tamper detection. Exports SOC2 / ISO 27001 compliance reports.
• Smart TTL — Audex estimates session duration from the command signature (aws s3 ls → 2m, terraform apply → 30m) so you don't have to guess.
• Natural Language Policies — tryaudex intent "read all my S3 buckets" → scoped IAM policy, generated via the Anthropic API.
• Policy Learning — Replay CloudTrail logs from a real run and generate the minimum IAM policy that would have let the command succeed.
• 20+ Built-in Profiles — s3-readonly, lambda-deploy, terraform-plan, gcs-readonly, dynamodb-query, and more. Short names for common permission sets.
• Credential Leak Detection — Scans command output for exposed access keys, tokens, and secrets before returning it to the agent.
• MCP Server — Native Model Context Protocol server for Claude Code, Cursor, Windsurf. Agents get audex_run, audex_sessions, audex_audit tools directly.
• TUI Dashboard — Interactive terminal UI (powered by Ratatui) with session overview, audit browser, top actions, cost attribution. Runs with zero arguments.
• Team Mode — Centralized server with API-key auth, per-identity rate limiting, and approval workflows. (Credential broker REST API and SAML / OIDC SSO on the roadmap.)
• High Availability (planned) — Redis leader election + Streams replication, or etcd leases and transactions. Not yet wired to a runtime client.
• Observability — OpenTelemetry traces, Prometheus metrics endpoint at /metrics, structured health checks.
• Native Rust — Single static binary, no daemons, no runtime. Cold start < 150ms. Credential issuance < 500ms end-to-end.

Installation

Quick Start

# Install from crates.io (recommended)
cargo install tryaudex

# First-run setup — prints the IAM trust policy you need, writes a starter config
tryaudex init

# Launch the interactive dashboard
tryaudex

# Or wrap a command immediately
tryaudex run --allow "s3:GetObject,s3:ListBucket" -- aws s3 ls

That's it. Run tryaudex --help to see the full command list.

Package Structure: tryaudex is the CLI binary published to crates.io. The core library (tryaudex-core) is also published separately for embedding Audex into your own Rust tooling.

Prerequisites

• Rust toolchain 1.74+ (only if building from source)
• Cloud credentials configured locally:
  • AWS: aws configure or AWS_* env vars — docs
  • GCP: gcloud auth application-default login — docs
  • Azure: az login — docs
  • Vault: VAULT_ADDR and VAULT_TOKEN env vars — docs
• An IAM role / service account / Azure principal that Audex can assume / impersonate. The base identity's permissions are the ceiling — Audex can only narrow, never widen.

From Source

# Install latest from GitHub main
cargo install --git https://github.com/Aditya-PS-05/tryaudex --bin tryaudex

# Or clone and build locally
git clone https://github.com/Aditya-PS-05/tryaudex
cd tryaudex
cargo build --release
./target/release/tryaudex --version

Note: Pre-built binaries will be published to GitHub Releases as the project matures. For now, cargo install is the recommended path.

Usage

Basic Commands

# Launch interactive TUI (default when no args)
tryaudex

# Wrap a command with scoped credentials
tryaudex run --allow "s3:GetObject" -- aws s3 ls

# List recent sessions
tryaudex sessions list

# View the audit log for a session
tryaudex audit show <SESSION_ID>

# Verify audit log HMAC chain integrity
tryaudex audit verify

# Generate an IAM policy from a natural-language intent
tryaudex intent "read objects from my-bucket"

# Launch the MCP server (for Claude Code / Cursor)
tryaudex mcp

AWS

1. Set your IAM role:

export AUDEX_ROLE_ARN="arn:aws:iam::123456789012:role/AudexAgentRole"

2. Run a command with scoped credentials:

# S3 read-only, default 15m TTL
tryaudex run --allow "s3:GetObject,s3:ListBucket" -- aws s3 ls

# Lambda deploy with an advisory budget cap (USD)
tryaudex run --ttl 30m --budget 5 \
  --allow "lambda:UpdateFunctionCode,lambda:GetFunction" \
  -- ./deploy.sh

# Restrict to specific resources
tryaudex run --allow "s3:GetObject" \
  --resource "arn:aws:s3:::my-bucket/*" \
  -- aws s3 cp s3://my-bucket/file .

# Use a named profile instead of --allow
tryaudex run --profile lambda-deploy -- ./deploy.sh

TTL note (AWS): sts:AssumeRole enforces 900s <= DurationSeconds <= 43200s (15 minutes to 12 hours). Audex clamps values outside that range and logs a warning. If you need sub-15m expiry, use short sessions and rotate — STS won't issue credentials shorter than 15m.

GCP

export AUDEX_GCP_SERVICE_ACCOUNT="agent@my-project.iam.gserviceaccount.com"

# Scoped GCS access
tryaudex run --provider gcp \
  --allow "storage.objects.get,storage.objects.list" \
  -- gcloud storage ls

# Using a built-in profile
tryaudex run --provider gcp --profile gcs-readonly -- gcloud storage ls

# BigQuery read-only
tryaudex run --provider gcp --profile bigquery-readonly \
  -- bq query --nouse_legacy_sql 'SELECT 1'

Azure

export AZURE_SUBSCRIPTION_ID="00000000-0000-0000-0000-000000000000"

tryaudex run --provider azure \
  --allow "Microsoft.Storage/storageAccounts/read" \
  -- az storage account list

# VM read-only profile
tryaudex run --provider azure --profile vm-readonly \
  -- az vm list

HashiCorp Vault

export VAULT_ADDR="https://vault.company.internal"
export VAULT_TOKEN="hvs.xxxxx"

# Vault-issued AWS credentials
tryaudex run --provider vault \
  --vault-role readonly-role \
  -- aws s3 ls

# Using Kubernetes auth
tryaudex run --provider vault \
  --vault-auth-method kubernetes \
  --vault-role my-service \
  -- aws s3 ls

Built-in Profiles

Profiles bundle common permission sets under a short name. Run tryaudex policy profiles to list all available profiles.

Provider	Profiles
AWS	s3-readonly, s3-readwrite, lambda-deploy, dynamodb-query, ec2-readonly, terraform-plan, terraform-apply, ecr-push, ecr-pull
GCP	gcs-readonly, gcs-readwrite, gce-readonly, gcf-deploy, bigquery-readonly
Azure	storage-readonly, vm-readonly

tryaudex run --profile lambda-deploy -- ./deploy.sh
tryaudex run --profile terraform-plan -- terraform plan

Sessions & Audit

# List all sessions (active + completed)
tryaudex sessions list

# Filter by status
tryaudex sessions list --status active

# Kill an active session (revokes its credentials immediately)
tryaudex sessions kill <SESSION_ID>

# View the audit trail for a session
tryaudex audit show <SESSION_ID>

# Recent audit entries across all sessions
tryaudex audit recent

# Verify the audit log HMAC chain
tryaudex audit verify

# Export audit logs in compliance-report format
tryaudex compliance export --format json --since 2026-01-01

Interactive Dashboard

tryaudex

Launches a Ratatui-powered TUI with eight tabs:

• Live — active sessions, sparkline rates (session/audit/failure), live event feed, top services bar chart
• History — browse sessions with master-detail split, lifecycle timeline, drift analysis, policy JSON
• Audit — scrollable audit log with session filtering and HMAC chain verification
• Spend — orphaned resource costs, burn summary, estimate-vs-actual comparison
• Safety — audit chain integrity, credential leak scan, approval-gated sessions, wildcard exposure
• Config — settings discovery with provenance tags ([env]/[file]/[default]), nested section status
• Policies — profiles (user + built-in), team profiles, universal deny list, role mappings
• Run — interactive command builder: pick provider, profile, TTL, toggles; live policy preview + cost estimate

Keyboard Navigation:

• 1-4 or ←/→/Tab: Switch tabs
• ↑/↓: Navigate lists
• k: Kill selected session
• f: Filter by provider / status
• r: Refresh data
• q: Quit

Natural Language Policies

Generate a scoped IAM policy from a description:

tryaudex intent "read objects from my-bucket and list DynamoDB tables"
# → s3:GetObject, s3:ListBucket (resource: my-bucket/*), dynamodb:ListTables

Requires ANTHROPIC_API_KEY. Uses the Claude API to produce a minimal policy scoped to the stated intent.

Policy Learning from CloudTrail

Observe what permissions a command actually needed, then generate the minimum policy:

# Run with broad scope, observe, then narrow
tryaudex learn --duration 15m -- ./deploy.sh
# → Replays CloudTrail events → suggests policy with only the actions that were used

This flips the usual IAM workflow: instead of guessing permissions upfront, you learn them from a real successful run.

Multi-Account Support

Configure multiple AWS accounts with aliases, deny lists, and per-account TTL caps in ~/.config/audex/accounts.toml:

[[account]]
name = "staging"
role_arn = "arn:aws:iam::111111111111:role/AudexAgentRole"
region = "us-east-1"
max_ttl = "30m"

[[account]]
name = "prod"
role_arn = "arn:aws:iam::222222222222:role/AudexAgentRole"
deny = ["*:Delete*", "iam:*"]
max_ttl = "10m"

tryaudex run --account prod --allow "s3:GetObject" -- aws s3 ls

Approval Workflows

For sensitive actions, require human approval before issuing credentials:

# ~/.config/audex/approvals.toml
[[approval_rule]]
match = ["*:Delete*", "iam:*", "ec2:TerminateInstances"]
approvers = ["alice@company.com", "bob@company.com"]
min_approvals = 1
timeout = "10m"

Audex pauses the session, sends an approval request to the configured channel (Slack / email / webhook), and issues credentials only after approval.

Chained Commands

Multi-step workflows with progressively narrowing scope:

tryaudex chain \
  --step "s3:ListBucket" --run "aws s3 ls s3://my-bucket" \
  --step "s3:GetObject" --run "aws s3 cp s3://my-bucket/report.csv ."

Each step gets its own credentials with its own policy — no step can inherit another's scope.

Configuration

Audex stores settings in ~/.config/audex/config.toml:

default_provider = "aws"
default_ttl = "15m"
audit_log_path = "~/.local/share/audex/audit.jsonl"
keystore_enabled = true
leak_detection = true

[tui]
theme = "blue"
auto_refresh = true
refresh_interval_ms = 2000

[telemetry]
otlp_endpoint = "http://localhost:4317"
metrics_port = 9090

Setting	Type	Default	Description
default_provider	string	"aws"	Provider to use when --provider not given (aws, gcp, azure, vault)
default_ttl	string	"15m"	Default session TTL if --ttl not given
audit_log_path	string	~/.local/share/audex/audit.jsonl	Append-only audit log location
keystore_enabled	bool	true	Cache credentials encrypted in the OS keyring
leak_detection	bool	true	Scan command output for exposed secrets
tui.theme	string	"blue"	TUI color theme (blue, green, monochrome, halloween, purple)
tui.auto_refresh	bool	false	Auto-refresh dashboard data
telemetry.otlp_endpoint	string	—	OpenTelemetry OTLP endpoint
telemetry.metrics_port	number	9090	Prometheus metrics port

Environment Variables

Environment variables override config file values. Useful for CI/CD or one-off runs. Audex-specific vars use the AUDEX_ prefix; provider-native vars (Vault, Azure, Anthropic) keep their conventional names so existing SDKs and docs still apply.

Variable	Prefix	Purpose
AUDEX_ROLE_ARN	audex	AWS IAM role to assume
AUDEX_GCP_SERVICE_ACCOUNT	audex	GCP service account email
AUDEX_CONFIG_DIR	audex	Override config directory (default: ~/.config/audex/)
AUDEX_DATA_DIR	audex	Override data directory (default: ~/.local/share/audex/)
AUDEX_PROVIDER	audex	Override default_provider
AUDEX_TTL	audex	Override default_ttl
AUDEX_NO_TELEMETRY	audex	Disable all OTLP/metrics emission
AZURE_SUBSCRIPTION_ID	native	Azure subscription ID (standard Azure SDK var)
VAULT_ADDR	native	HashiCorp Vault address (standard Vault CLI var)
VAULT_TOKEN	native	Vault auth token (standard Vault CLI var)
ANTHROPIC_API_KEY	native	Required for tryaudex intent (natural-language policies)

# Example: one-off CI run with 2-minute credentials, no telemetry
AUDEX_TTL=2m AUDEX_NO_TELEMETRY=1 tryaudex run --allow "s3:GetObject" -- aws s3 ls

MCP Integration

Audex ships as a Model Context Protocol server. Claude Code, Cursor, Windsurf, and any MCP-compatible agent get three native tools: audex_run, audex_sessions, audex_audit — no shell wrapping needed.

Add to your project's .mcp.json:

{
  "mcpServers": {
    "audex": {
      "command": "tryaudex",
      "args": ["mcp"]
    }
  }
}

Make sure AUDEX_ROLE_ARN (or the GCP / Azure equivalent) is set before starting your agent. The agent requests scoped credentials natively from its tool interface; Audex enforces the policy, TTL, and audit trail transparently.

Ready-to-copy configs:

• examples/mcp-configs/claude-code.json — Claude Code
• examples/mcp-configs/cursor.json — Cursor IDE
• integrations/claude-code/ — Claude Code hooks that auto-wrap aws / gcloud / az calls

Team Mode (Server)

Run Audex as a centralized server with SSO, rate limiting, and a REST API. Currently AWS-only in server mode (GCP/Azure support planned):

tryaudex server --bind 0.0.0.0:8080 --config /etc/audex/server.toml

• API-key bearer auth today — SAML / OIDC SSO on the v0.6 roadmap
• Per-identity rate limits — prevent a single compromised agent from burning through the API
• Redis or etcd backend (planned) — for HA deployments (leader election + replicated session state)
• Prometheus metrics at /metrics — request rate, credential-issuance latency, active sessions
• Credential broker REST API (planned) — batch requests, broker tokens, delegated issuance. Client library exists but server endpoints not yet implemented.
• Webhook / Slack notifications — approval requests, policy violations, drift alerts

See the team-mode guide for deployment details (Kubernetes, systemd, Docker Compose).

How It Works

┌──────────────┐     ┌───────────────┐     ┌─────────────┐
│  Your Agent  │────>│    Audex      │────>│   AWS STS   │
│  (claude,    │     │  - Policy     │     │  AssumeRole │
│   cursor,    │     │  - TTL        │     │  + Inline   │
│   etc.)      │     │  - Audit Log  │     │    Policy   │
│              │<────│               │<────│             │
└──────────────┘     └───────────────┘     └─────────────┘
       ^                                          │
       └─── AWS_ACCESS_KEY_ID <───────────────────┘
            AWS_SECRET_ACCESS_KEY
            AWS_SESSION_TOKEN

1. You run tryaudex run --allow "s3:GetObject" -- aws s3 ls
2. Audex parses the allowed actions into an IAM policy document
3. Audex calls sts:AssumeRole with your role ARN and an inline session policy
4. AWS returns temporary credentials valid for the specified TTL
5. Audex injects them as environment variables and spawns your command
6. When the command exits (or TTL expires), credentials stop working
7. Session metadata, events, and API calls are written to the audit log

The effective permissions are the intersection of the role's attached policies and the inline policy. Even if the role has s3:*, the session can only use s3:GetObject.

For GCP, Audex calls iamcredentials.generateAccessToken on an impersonated service account. For Azure, it issues scoped RBAC role assignments. For Vault, it proxies through the configured secrets engine. Same surface, four backends.

Security Model

• Scoped — Session policies restrict credentials to exactly the specified actions. No ambient authority.
• Short-Lived — TTL enforced by the cloud provider (AWS STS, GCP IAM Credentials API), not by Audex. Process kill doesn't leak credentials.
• Auditable — Append-only JSONL log with HMAC-SHA256 chain. Tampering detectable via tryaudex audit verify.
• No Secrets on Disk — Only session metadata (ID, policy, expiry, exit code) is stored locally. Credentials live in process memory.
• Leak Detection — stdout/stderr scanned for credential patterns (AWS keys, GitHub tokens, private keys) before returning to the agent.
• Encrypted at Rest — Optional OS keyring cache (macOS Keychain, GNOME Keyring, Windows Credential Locker) for credential reuse within TTL.
• HA & Replication (planned) — In team mode, sessions will be replicated via Redis Streams or etcd with leader election. Not yet wired to a runtime client.

See docs/security-model.md for the full HMAC chain algorithm, exact threat model, and honest caveats (hardcoded default key, truncation, key rotation). Also mirrored at tryaudex.adityaps.work/docs/security-model.

Documentation

Deep technical references live in docs/ and are browsable directly on GitHub:

Document	What it covers
troubleshooting.md	Nine common errors with diagnosis + fix — AUDEX_ROLE_ARN not set, AccessDenied, TTL >1h role-chaining cap, MCP startup issues, audit verify output, log/config paths
security-model.md	Exact HMAC-SHA256 chain algorithm, what tampering it detects, what it does NOT prevent (public default key, truncation, filesystem attacker), production hardening checklist
migrating-from-aws-vault.md	Concept mapping table, step-by-step migration from aws-vault, FAQ for switchers
design-killer-demo-5-users.md	Original product strategy doc — demand-validation approach, success criteria, distribution plan

The hosted documentation site at tryaudex.adityaps.work/docs covers CLI reference, multi-cloud setup, policies, team-mode deployment, MCP server integration, and dashboard usage.

Development

Quick setup: If you just want to run Audex, see the Quick Start. This section is for contributors.

Prerequisites

# Rust (required)
rustc --version   # 1.74+
cargo --version

# Optional: nightly toolchain for fuzzing
rustup toolchain install nightly

How to Run

# Clone and build
git clone https://github.com/Aditya-PS-05/tryaudex
cd tryaudex
cargo build --workspace

# Run the CLI in debug mode
cargo run -- run --allow "s3:GetObject" -- aws s3 ls

# Run the interactive TUI
cargo run -- 

# Run all tests (265+ unit + integration)
cargo test --workspace

# Lint
cargo clippy --workspace -- -D warnings

Advanced Development

Project Scripts

Script	Description
cargo build --workspace	Build both tryaudex CLI and tryaudex-core library
cargo test --workspace	Run unit, integration, and property tests
cargo clippy --workspace -- -D warnings	Lint all crates with warnings as errors
cargo bench	Run Criterion benchmarks
cargo +nightly fuzz run fuzz_policy_parser	Run policy parser fuzzer (from fuzz/)

Workspace Layout

• crates/audex-core — Policy engine, session management, credential issuance, audit logging, HA primitives. Published as tryaudex-core.
• crates/audex-cli — CLI binary, TUI dashboard, MCP server. Published as tryaudex.
• fuzz/ — libFuzzer targets for policy, audit, and config parsers.
• integrations/ — Terraform modules, Kubernetes manifests, Python SDKs (LangChain, CrewAI, OpenAI Agents), Claude Code hooks.
• web/ — Astro + Starlight documentation site at tryaudex.adityaps.work.
• benchmarks/ — Latency benchmarks (credential issuance, audit write, policy parse).

Testing

# Unit tests
cargo test --workspace --lib

# Integration tests (hits real providers with dry-run mode)
cargo test --workspace --test '*'

# Property tests (proptest)
cargo test --workspace --test proptest_invariants

# Chaos tests (simulate network failures, clock skew)
cargo test --workspace --test chaos

Fuzzing

cd fuzz
cargo +nightly fuzz run fuzz_policy_parser
cargo +nightly fuzz run fuzz_audit_reader
cargo +nightly fuzz run fuzz_config_parser

Benchmarks

./benchmarks/run_benchmark.sh
./benchmarks/latency_benchmark.sh

Measures credential issuance latency, audit-log write throughput, policy parse speed, and end-to-end wrap overhead.

Supported Platforms

Platform	Architecture	Status
macOS	x86_64	✅ Supported
macOS	aarch64 (Apple Silicon)	✅ Supported
Linux	x86_64 (glibc)	✅ Supported
Linux	aarch64 (glibc)	✅ Supported
Linux	x86_64 (musl)	✅ Supported
Windows	x86_64	✅ Supported
Windows	aarch64	🚧 Experimental

Audex is a single statically-linked Rust binary. No runtime, no daemons, no services. Drop it on any machine with cloud credentials and you're done.

CLI Reference

tryaudex run [OPTIONS] -- <COMMAND>...
  --provider <PROVIDER>      Cloud provider: aws, gcp, azure, vault [default: aws]
  --allow <ACTIONS>          Comma-separated IAM actions
  --profile <NAME>           Named policy profile
  --resource <ARN>           Restrict to specific resource ARNs
  --ttl <DURATION>           Session time-to-live [default: 15m]
  --budget <USD>             Advisory budget limit
  --account <NAME>           Multi-account alias
  --role-arn <ARN>           AWS role [env: AUDEX_ROLE_ARN]
  --service-account <EMAIL>  GCP service account [env: AUDEX_GCP_SERVICE_ACCOUNT]
  --vault-role <NAME>        Vault role for AWS secrets engine

tryaudex chain <STEPS>       Multi-step chain with progressive scoping
tryaudex sessions list       List all sessions
tryaudex sessions kill <ID>  Revoke a session
tryaudex audit recent        Recent audit entries
tryaudex audit show <ID>     Audit log for a session
tryaudex audit verify        Check HMAC chain integrity
tryaudex clean               Clear local sessions and audit logs
tryaudex init [--provider]   Guided setup: trust policy + starter config
tryaudex intent <PROMPT>     Natural language → IAM policy
tryaudex learn -- <CMD>      Learn minimum policy from CloudTrail
tryaudex compliance          Export SOC2/ISO 27001 reports
tryaudex dashboard           Usage dashboard with top actions
tryaudex estimate -- <CMD>   Estimate cost before issuing
tryaudex health              Check provider connectivity
tryaudex metrics             Serve Prometheus metrics
tryaudex replay <ID>         Replay a past session
tryaudex watch <ID>          Watch live CloudTrail API calls
tryaudex server              Run centralized HTTP API (team mode)
tryaudex mcp                 Start MCP server
tryaudex                     Launch TUI dashboard (default)

Run tryaudex <command> --help for full flag documentation on any subcommand.

Contributing

Contributions are welcome. See CONTRIBUTING.md for the full guide — repo layout, test tiers (unit / chaos / proptest / integration), code style, commit conventions, how to add a built-in policy profile, and how to report security issues.

TL;DR for a first PR:

1. Fork the repo and create a feature branch.
2. Make your change, add a test.
3. Run the CI checks locally:

   cargo fmt --all -- --check
   cargo clippy --workspace --all-targets --all-features -- -D warnings
   cargo test --workspace --all-features

4. Commit with a Conventional Commits message (feat:, fix:, docs:, etc.).
5. Open a PR describing the why, not just the what.

Acknowledgments

• AWS STS, GCP IAM Credentials API, and HashiCorp Vault for the credential-issuance primitives Audex stands on
• Ratatui for the terminal UI framework
• rmcp for the Rust MCP server implementation
• clap for the CLI ergonomics
• tokscale for the README layout inspiration
• Every security researcher who has written about prompt-injection and supply-chain attacks on AI-coding workflows — this tool exists because of that work

License

MIT © Aditya Pratap Singh

If you find this project useful, please consider starring it ⭐ or follow me on GitHub for more work on AI infrastructure and cloud security. Issues, PRs, and ideas all welcome.