Platform
Amajoni connects to your AWS account with read-only permissions, discovers the AI agents running in it, scores what each one could do if it were compromised, and produces the evidence your auditor asks for. Nothing is installed and no policy is modified.
Capabilities
Amajoni walks Lambda, ECS, SageMaker, Step Functions, Bedrock Agents, EC2 and more, looking for evidence of LLM activity — a bedrock: permission, an ANTHROPIC_API_KEY, an agent framework on the runtime. Findings are classified Confirmed when there is direct evidence of model invocation, and Possible when the signal is circumstantial.
A misleading name is not evidence. A role called ai-agent-orchestrator with nothing but log permissions is not reported as an agent.
Every agent scores 0–100 against the IAM permissions it actually holds, not a category label. The score is never a single opaque number: each agent carries a breakdown naming which permission contributed what, and a list of the specific dangerous permissions behind it. Configuration hygiene — missing tracing, unencrypted logs, no guardrail — is reported as posture beside the score, never added to it.
Full detail in How scoring works below — including what we deliberately score at zero.
A Lambda function and the execution role it runs as are one agent, not two. Agents are reconciled across scans so triage state survives, and agents that stop appearing age out of the active inventory rather than lingering forever.
Suppression is conservative: a role is only merged away when it is the confirmed execution role of a compute resource in the same scan.
Each agent carries an owner, an approval status (approved, rejected, pending review, unreviewed) and a review cadence. Ownership answers the question that stalls most remediation: who is allowed to turn this off.
Approval changes are permission-gated by role and written to the audit log.
Alerts are deduplicated on a stable fingerprint, so the same finding across two scans is one alert with history, not two entries. Triage state persists across scans even when the underlying values change.
The goal is an alert list that shrinks when you work it.
Findings map to six frameworks and are stated as Met or Not Met against the scan that produced them. Where a control is not met, the report says so.
Reports are generated from scan data. There is no manual status field to fudge.
Coverage
Stated plainly, including what is not built yet. You should not find out the limits of a security tool during an incident.
Lambda, IAM, ECS, SageMaker, Step Functions, Bedrock, EC2, S3, Secrets Manager and more — 19 services read during a scan.
Manual registration, not automated discovery. Agents are registered by hand and then scored, governed and reported on exactly like discovered ones. This is the path used for our Brown Hat Academy pilot.
Not supported yet. Automated discovery for these clouds is on the roadmap and is not something you can run today.
How scoring works
Blast radius answers one question: if this agent were fully compromised tomorrow, how much damage could it do with the permissions it already holds? It is computed from the agent's resolved IAM policy — including inherited and inverted grants — never from its name, tags or team.
Categories are additive and capped at 100. An agent is never charged twice for the same permission.
| Category | Points | Why it counts |
|---|---|---|
| Admin wildcard (* on *) | 100 | Unrestricted. Nothing else needs to be considered. |
| Remote code execution | 30 | Can run arbitrary code on your infrastructure. |
| STS lateral movement | 30 | Can assume other roles and leave its own blast radius. |
| IAM / Bedrock actions | 25 | Model invocation, or the ability to alter permissions. |
| Code / supply-chain write | 25 | Can modify what later runs in your pipeline. |
| Secrets & credential access | 20 | Can read the credentials other systems trust. |
| Prompt injection pathway | 15 | Consumes untrusted input that reaches a model. |
| Database write | 15 | Can alter or delete stored records. |
| Data lake query / exfil | 15 | Can bulk-read analytical data. |
| S3 write / delete | 10 | Can alter or destroy object storage. |
| Internet exposed (modifier) | +8 | An unauthenticated Function URL or public endpoint means anyone can trigger it. |
| High call volume (>500/hr) (modifier) | + | The same permissions exercised more often. |
Every Lambda on AWS holds the same three log-writing permissions, and most hold X-Ray and VPC networking permissions too. They are the price of running a function at all, not a capability anyone chose to grant. Scoring them would add points to every agent equally — which raises every number without changing a single ranking, and buries the agents that genuinely matter.
So the standard execution-role actions are exempt, and they never appear in an agent's dangerous-permissions list. A broad grant like logs:* is a different thing and is treated as one.
Connecting
Security teams have different rules about what may leave the building. Both options are read-only and produce an identical scan.
You deploy a small CloudFormation stack that creates a read-only role trusting Amajoni, guarded by an external ID unique to your organisation. Nothing long-lived is handed over, and access ends the moment you delete the stack.
You paste the key and secret of a read-only IAM user. They are used for that one scan and are never written to our database. Useful when deploying a stack needs a change request you would rather not raise to evaluate a tool.
Either way the permissions are the same and the scan is the same. We recommend the role because it means you never hand anyone a standing credential — but if keys get you an answer this week instead of next quarter, use keys.
Architecture
Amajoni reads your account and writes nothing to it. Across the 19 AWS services the scanner touches, every call is a describe, get or list.
That is not a policy we ask you to trust. A test in our build pipeline parses the scanner and fails the build if a mutating AWS call is ever introduced — so the guarantee cannot quietly regress between releases.
# permissions the scanner needs
AmajoniReadOnlyScan
an exact list of List, Get and Describe
actions on configuration metadata
·
# permissions it does not ask for
iam:*
lambda:UpdateFunctionConfiguration
s3:PutObject
secretsmanager:PutSecretValue
A read-only connection and a scan. No agent installed, no policy modified, no production traffic touched.