Should AI take that autonomous action? Probably not.

· 2 min read

Artificial Intelligence Security

Classifying AI Actions Into Risk Levels

Organizations have long classified data sensitivity to control who can access it, what can be done with it, and when it can be removed. We now need the same discipline for AI actions, especially in agentic systems capable of proposing or initiating changes.

The core principle is simple:

Treat AI like a new employee with zero authorization. Every action must be gated, reviewed, or approved based on risk.

By evaluating the implications of each action, we can classify them into clear risk tiers:

Low Risk: Autonomous action allowed

Actions with no operational, security, or regulatory impact. Examples:

  • Summaries
  • Formatting adjustments
  • Basic Q&A
  • Non privileged recommendations

Medium Risk: Human review recommended

Actions that influence code or systems but cannot directly cause harm. Examples:

  • Code hints
  • Language or documentation changes
  • Model evaluation proposals
  • Infrastructure suggestions

High Risk: Human approval required (named risk owner)

Actions that modify systems, touch sensitive data, or affect security posture. Examples:

  • Code check ins
  • Access to sensitive data
  • Infrastructure changes
  • Model deployments
  • Any security relevant modification

Critical Risk: Dual human approval + immutable audit trail

Actions with catastrophic blast radius if incorrect. Examples:

  • Production deployments
  • Cryptographic changes
  • IAM modifications
  • Access to highly sensitive or regulated data
  • Any action requiring pre deployment testing and scripted execution

Additional Key Principles

1. Human authorization must use non‑spoofable, non‑replayable tokens

Approval must be cryptographically bound to a human identity and impossible for AI to forge or reuse.

2. It must be structurally impossible for AI to perform unauthorized actions

The AI should never hold privileged roles, long lived credentials, or direct access to production systems.

3. Agents must not touch production, tokens, cryptography, or IAM

For high risk or critical actions, the AI should only produce reviewable scripts or proposals, never execute them.

4. IAM and cryptographic changes must remain invisible to agents

Agents should not see, modify, or even be aware of production IAM or cryptographic configurations.

5. Provenance validation must occur outside the agent

If cryptographic provenance (SBOM/CBOM) is used, validation must be performed by a trusted external process, not by the agent itself.

6. Keep tokens out of the agent’s hands

Use one time, scoped human tokens processed by a separate, minimal execution broker that:

  1. Verifies the agent request
  2. Requires human approval
  3. Obtains a short lived, scoped token
  4. Executes the approved action deterministically
  5. Logs the action and binds it to the human risk owner
  6. Invalidates the token
  7. Wipes token and execution details from memory
  8. Returns only a simple success/fail back to the agent

This ensures the agent never becomes privileged and cannot escalate.