# AI agent security: define access and responsibilities

Frame AI agent security through permissions, data boundaries, sensitive actions, human approval, incident handling and maintenance ownership.

Author: Binov

Canonical: https://www.binov.com/en/guides/ai-agent-security-governance

AI agent security concerns the data it can read, the tools it can use and the actions it can trigger. Enforce those boundaries in the application and assign clear ownership. A prompt alone is not an access control.

## Map system boundaries

List users, sources, tools and destination systems. For each exchange, identify the credentials used, information transmitted and available operations. This shows where a model decision can become a real action.

Distinguish information being read from authorised instructions. A document or incoming message may try to redirect the system’s behaviour. [OWASP describes prompt injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) as a relevant risk at this boundary.

## Match controls to actions

| Action | Control to examine |
| --- | --- |
| Read information | User permissions and scope |
| Prepare a proposal | Sources, limitations and review context |
| Change a record | Authorisation and operation data |
| Send a message | Recipient, content and approval |
| Retry an operation | Duplicate prevention and limits |

Place human review before the action concerned and show enough detail to support a meaningful decision.

## Test boundaries directly

Include out-of-scope requests, less-privileged users, contradictory sources and suspicious instructions in documents. Verify both what the system displays and what it actually executes.

A well-worded refusal is insufficient if a tool was still called. Application checks and logs should establish the real behaviour rather than only the generated explanation.

## Assign responsibilities

Name business, technical and data owners. Decide who approves a new tool, expanded permissions or a model change. A deployed capability continues to change and needs ongoing ownership.

A risk management approach can help organise these decisions. The [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework) is a general reference; using it does not establish certification or compliance for a product.

## Prepare incident handling

Define how to stop an action, revoke access and identify affected operations. Retain information needed for investigation within an appropriate scope and duration. Logs should not become an uncontrolled copy of business documents.

Prepare user communication and a manual fallback. After a fix, rerun the cases that exposed the problem before broadening usage again.

## Common questions

**Can we grant broad access to simplify a prototype?** A prototype still needs explicit boundaries. Excessive permissions increase the consequences of mistakes and weaken the relevance of its findings.

**Must every action be approved manually?** Controls should match the consequences and be defined by action category, then verified in operation.

**Does security work end at launch?** No. New tools, users and data change the scope to examine.

Capture these decisions in [agent requirements](/en/guides/ai-agent-requirements) and [production planning](/en/guides/ai-poc-to-production). Explore [Binov’s technical leadership support](/en/services/cto-as-a-service).