AI agent security controls what an agent can access and what it can cause to happen. Once an agent can use tools, move funds, or change a production system, its security depends on the services that carry out those actions as well as the model that proposes them.
For an enterprise, the useful question is concrete: if an agent submits a valid request for an action the business has not authorized, which control stops it?
What needs protection?
An agent has several security boundaries. Its runtime holds credentials and processes untrusted information. Its tools expose data and operations. The connected applications decide whether to create a business effect.
Protecting only one boundary leaves the others exposed. A well-isolated runtime can still submit an unauthorized request through a permitted tool. A correctly authenticated agent can still request an excessive transfer. A policy decision can be bypassed if the executing service accepts another route.
OWASP's guidance on excessive agency identifies overly broad capabilities, permissions, and autonomy as sources of damaging actions. Its recommendations make a useful starting point for reviewing what an agent actually needs.
Which controls belong in an AI agent security architecture?
| Layer | The decision it should enforce | Evidence to request |
|---|---|---|
| Agent identity | Which agent or workload is making the request? | Scoped credentials and independently revocable identities |
| Runtime and network | What can the agent process read, run, and reach? | Isolation, secret handling, and egress rules |
| Tool access | Which tools and resources may this identity use? | Permission checks for the requested resource |
| Action policy | Is this exact operation within its authority? | Rules over the operation's meaningful fields |
| Human approval | Which operations require an independent decision? | Approval bound to the operation under review |
| Execution | Does the operation being performed match the authorization? | Mandatory verification at the service that creates the effect |
| Resilience and audit | What happens when a participant is breached or unavailable? | A stated compromise threshold, recovery plan, and decision records |
These controls can come from several systems. Evaluate whether their decisions stay attached to the same operation across the complete execution path.
How do MCP security and action authorization differ?
The Model Context Protocol connects agent hosts with tools and resources. Transport authentication and authorization govern access to an MCP server. Tool discovery and input schemas help the host understand how to call it.
The business operation needs its own checks. Being permitted to call a payment tool does not authorize every recipient and amount that its schema accepts. The action policy must evaluate those values, and the payment service must enforce the accepted request.
AI agents can manage Keeper through TKeeper Hub’s MCP tools, including identity discovery, policies, signing, approvals and system operations. Tools use the authenticated user’s permissions; Keeper still enforces the authority policy and required approvals. See how to secure AI agent tool calls for the integration boundary.
What should happen after a policy decision?
An accepted decision must reach the executing service without becoming detached from the action it covers. The service needs to know the expected identity, the authorized fields, and the conditions under which the authorization is still valid.
In TKeeper, the authorization takes the form of cryptographic proof for the requested operation. The receiving system verifies that proof before creating the effect. It also handles the applicable freshness, replay, and application-state checks.
The integration must make verification mandatory. An agent that retains direct administrative credentials to the same backend may have a route around the protected path. The verifier contract describes this requirement.
When does human approval help?
Human approval is useful when a request has consequences that the standing policy should not decide alone. The reviewer needs the actual operation and its relevant values, rather than the agent's description of what it intends to do.
An approval should cover the same action that policy evaluates and the backend executes. Changing a relevant field should require a new decision. Define which independent approvers are required and how an expired or reused approval is rejected.
TKeeper verifies approval proofs supplied by the integration. It does not replace the business's approval workflow. Read human approval for AI agent actions for the distinction between approval groups, policy, and threshold signing.
How should a CISO evaluate an AI agent security product?
Start with the control the organization needs to enforce. Discovery and monitoring help teams understand deployment and behavior. Sandboxing limits what an agent runtime can reach. Authorization controls which operations may proceed. Their coverage differs.
Ask a prospective provider:
- Which system can actually refuse the operation, and can the agent bypass it?
- Are policy and approvals bound to the operation's exact fields?
- What happens when a policy dependency, audit destination, or signing participant is unavailable?
- What can one compromised agent, operator, or host authorize?
- Which records let a reviewer reconstruct the accepted request?
- Which guarantees have executable tests, and which assumptions remain with the integration?
Require evidence for the answers. A demonstration of a successful request says little about whether an altered, expired, or out-of-scope request is rejected.
When does TKeeper fit?
TKeeper fits teams that need a self-hosted authorization boundary for AI tool calls, agentic payments, digital asset transfers, or other critical machine actions. It applies policy and required approvals to typed requests and can distribute cryptographic authority across threshold peers.
The selected threshold and placement of peers determine the compromise and availability boundary. Fewer than the required peers cannot authorize an operation alone. Availability still requires enough healthy participants. See quorum modes and security assurance for assumptions and tested behavior.
TKeeper does not discover every agent in an organization, classify prompts, or secure an agent's runtime. Those controls remain part of the wider architecture. Use the AI agent security solution to assess the authorization capabilities and the threat model to review their limits.
For agents that handle money, continue with AI agent wallet security and agentic payment security.