Solutions · Security

Agentic AI security for enterprise actions

Control what AI agents do, not only what they say: permissions, named-person approvals, and spending limits on actions routed through AAES, with records you can check for integrity offline.

By AAES Last reviewed:

Agentic AI security is the discipline of controlling what AI agents do, not only what they say: identity, permissions, credential custody, spending limits, and evidence for actions taken with enterprise systems. AAES (Autonomous Agentic Enterprise Systems) works at this action layer. Enforcement requires control of the agent's credential path. Other activity is visible only where telemetry is supplied; observation cannot block it.

The action-layer threat model

An agent connected to enterprise systems fails differently from a chatbot. The failures worth engineering against are operational, not rhetorical:

  • Over-permission. The agent holds broad credentials because scoping them per task was inconvenient, so one confused or manipulated request can reach far more than the task requires.
  • Irreversible actions without review. Payments, production changes, and external messages execute before a person has seen the exact request.
  • Unbounded spend. Retries and loops turn a small error into a large bill because nothing reserves a budget before dispatch.
  • Bypass. The agent keeps a direct credential path around whatever control was deployed, so the control cannot stop the call and sees it only where telemetry happens to report it.
  • Unverifiable records. After an incident, the only account of what happened is a dashboard that requires the vendor's service to read.

Prompt injection and content filtering matter, but they are model-layer defenses. None of them, by itself, constrains what happens after the model decides to act.

Controls AAES provides

AAES sits on the action path and checks every request on enforced paths before a supported call is dispatched:

  • Per-capability permission. Agents are registered with at least one accountable human manager and permission for specific capabilities. Requests outside that set are refused and recorded.
  • Named-person approval. AAES requires an authorized person’s approval for capabilities registered as irreversible. Each approval covers the exact request, expires, and cannot be supplied by the requesting agent.
  • Budget reservation. Configured budgets are reserved before dispatch; requests over the ceiling are refused.
  • Credential custody. On a grant path, AAES issues short-lived permission for a specific task, called an AAES grant. This is an authorization, not a credential for the downstream service. On a brokered-execution path, AAES uses the configured credential to make the permitted call and returns the result without giving that credential to the agent. A short-lived grant does not shorten the lifetime of the downstream secret. Observation-only registrations record reported activity and cannot stop the call.
  • Sealed, exportable records. Check exported records for integrity without connecting to an AAES service.

Observation-only registrations record reported activity and cannot stop the call. For MCP-connected agents specifically, the MCP security checklist covers transport authorization versus business permission, and where the AAES adapter's documented limits are. For platform evaluation criteria, see the AI governance platform overview.

What AAES does not secure

Bypassed paths. Enforcement requires control of the agent's credential path. Other activity is visible only where telemetry is supplied; observation cannot block it.

Data after receipt. AAES does not control what an agent does with data it was permitted to receive, and it does not govern model behavior, prompts, or content.

Availability. If AAES is unavailable or cannot write the required decision journal, new requests on enforced paths are refused. This is called fail closed. Grants issued before the failure remain usable until expiry, at most 15 minutes from issue.

Assurance status. No SOC 2 report exists, and no penetration test has been performed. The dated capability matrix lists which credential paths are implemented, lab-only, planned, or refused.

Test the controls, don't read about them

On one bounded workflow, attempt the actions your threat model worries about. An irreversible call without approval, an approval reused on a changed request, and a self-approval attempt should each be refused and leave a record. Concurrent requests near a budget limit must not double-spend. A direct-credential bypass is not stopped by AAES; confirm at the downstream provider that a refused action had no effect, and verify the exported records with the network disabled. The evaluation guide walks through the procedure.

The platform evaluation package runs in your environment and is included only in the paid design partnership. The design-partner offer is USD 40,000 for three months; the term begins once the agreement is signed and onboarding is complete.

Request an evaluation

Frequently asked questions

How is agentic AI security different from AI model security?

Model security protects the model: its weights, prompts, and outputs. Agentic AI security controls what a deployed agent does with connected systems: which capabilities it may call, who approves irreversible actions, and how much it may spend. A secure model can still take an unwanted action if nothing constrains the action path. AAES addresses the action path; model, prompt, and content protections remain separate tooling.

Does AAES replace an AI gateway or guardrails product?

No. Gateways and guardrails products filter model traffic and content; AAES gates the actions an agent takes with enterprise systems, through permissions, named-person approvals, and budget checks on requests routed through it. The layers are complementary. Enforcement requires control of the agent's credential path; activity outside AAES is visible only where telemetry is supplied, and observation is not enforcement.

What happens to agent actions if AAES is unavailable?

If AAES is unavailable or cannot write the required decision journal, new requests on enforced paths are refused. This is called fail closed. Grants issued before the failure remain usable until expiry, at most 15 minutes from issue. Availability is operated by the client; no product availability SLA is offered today.

How do we test AAES agentic AI security controls?

On one bounded workflow: attempt an irreversible action without approval, reuse an approval on a changed request, and let the agent try to approve itself; each should be refused and recorded. Concurrent requests near a budget limit must not double-spend. A direct-credential bypass is not stopped by AAES; confirm at the downstream provider that a refused action had no effect. The platform evaluation package runs in your environment and is included only in the paid design partnership.

Related reading: the AI agent access control worksheet, the AI agent spending controls guide, and the AI agent governance comparison.