Secure AI agent architecture: tools, permissions and action control

A secure AI agent does not receive direct, unrestricted access to business systems. The model proposes a structured action, policy checks permission and risk, an isolated executor performs it, and the result is validated and audited. Irreversible or sensitive operations require separate approval.

A chatbot produces text. An agent can plan, call tools, read data, retain memory and change external state. That ability expands both value and attack surface.

Threat model

Consider at least six risk sources:

• direct hostile instructions from a user;
• indirect instructions inside a document, email, web page or API result;
• excessive tool permissions;
• model misunderstanding or incorrect parameters;
• uncontrolled retries, recursion and delegation;
• sensitive data leaking through memory or logs.

An internal document is still untrusted input. It may be outdated, incorrect or deliberately crafted to influence the agent.

Separate decision from execution

The model should not directly run arbitrary commands:

Request → context → model → structured intent
→ policy → approval if required
→ constrained executor → result validation → audit

The model returns an object with a known schema, not a shell string:

{
  "action": "create_support_ticket",
  "customerId": "c-1842",
  "priority": "normal",
  "summary": "Delivery status requires investigation"
}

The executor accepts only known actions and fields, validates types and permissions again, and rejects unknown input.

Design narrow tools

Avoid a generic tool such as execute_sql(query). Prefer business operations such as get_order_status(orderId) or create_support_ticket(customerId, category, summary).

Narrow tools reduce possible actions, simplify authorisation, support parameter validation and produce understandable audit records.

Give the agent and every environment separate service identities. The effective permission is the intersection of user permission and agent permission.

Classify action risk outside the model

Level	Example	Control
Low	Find an instruction	Automatic with logging
Medium	Create a draft ticket	Validation and cancellation
High	Send a customer message	Human approval or strict policy
Critical	Payment, deletion, access change	Separate workflow, MFA, dual control

The model must not decide that its own action is low risk. Classification belongs to the tool policy.

Protect retrieval and memory

For retrieval-augmented generation:

• index only approved sources;
• store owner, date and classification;
• apply ACLs before retrieval;
• separate system rules from document content;
• treat retrieved text as evidence, not instruction;
• require citations;
• limit context volume;
• test indirect attacks.

Where an answer triggers action, verify critical facts through an authoritative API rather than trusting generated prose.

Separate step context, user session, explicitly approved profile memory, action audit and the corporate knowledge base. Define owner, retention, encryption, access and deletion for each. Never mix memory between users or tenants.

Limit autonomy technically

Enforce outside the prompt:

• maximum steps and duration;
• per-tool and total call counts;
• token and cost budgets;
• allowed network destinations;
• read/write volume;
• delegation depth;
• retry count;
• action expiry.

Use idempotency keys for changing operations so a retry cannot create duplicate tickets or messages. See API integration architecture.

Make approval meaningful

An approver needs to see what will change, the target object, source data, proposed parameters, evidence, risk, rollback options and approval expiry.

Do not hide hundreds of different actions behind one confirmation. Bulk operations need sampling, limits and a result report.

Isolate execution

File or code processing belongs in a sandbox with a minimal image, isolated filesystem, CPU/memory/time limits, restricted networking, destination allowlists, one-time credentials, cleanup and result scanning.

Secrets do not belong in prompts. The executor receives a short-lived token only after policy approval.

Observability without leakage

Use one trace ID across request, model and policy version, retrieved sources, proposed action, policy result, approval, tool call, result validation and final response.

Do not log complete prompts by default when they may contain personal data or secrets. Store structured metadata, version hashes and redacted fragments.

Track task success, manual correction, denied actions, false blocks, steps per task, P95 duration, cost, loops, tool failures and incidents by version.

Evaluation and incident control

The evaluation set should include normal tasks, ambiguity, missing data, conflicting documents, direct and indirect manipulation, cross-user data, expired permission, tool outage, retries and model changes.

Define acceptable actions and forbidden consequences for each case. Run regression tests after changes to the model, prompt, tools, memory, retrieval or policy.

Provide a kill switch outside the agent system, credential revocation, queue isolation, evidence preservation, affected-object reporting, version rollback and manual recovery. Exercise the procedure.

Staged pilot

1. Choose a reversible workflow such as drafting or classification.
2. Define data, tools, owner and measurable success.
3. Build narrow tools with schemas, identities, idempotency and audit.
4. Implement policy, risk and approval outside the model.
5. Create evaluations from anonymised real scenarios and boundary attacks.
6. Run shadow mode where the agent proposes but does not execute.
7. Allow a small user, object and daily-budget scope before expanding.

Production checklist

• Generation is separated from action.
• Every tool has a narrow contract.
• The model does not authorise itself.
• User and service permissions intersect.
• ACLs apply before retrieval.
• Memory is isolated and retained for a defined period.
• High-risk actions have meaningful approval.
• Steps, time, cost and retries are limited.
• Changing operations are idempotent.
• Code and file execution is sandboxed.
• Evaluation gates releases.
• Audit links decisions to actions.
• The kill switch is tested.
• A business owner is accountable for outcomes.

Conclusion

Agent security begins with architecture rather than a perfect prompt. The model proposes, policy permits, a narrow tool executes, people approve high risk, and telemetry proves what happened.

Useful references include the NIST AI Risk Management Framework, OWASP AI Agent Security Cheat Sheet and OWASP Securing Agentic Applications Guide. They do not replace applicable Russian requirements or an organisation’s threat model.

Recent platform context is covered in the Selectel–ITMO multi-agent announcement and our analysis of China’s agent-interoperability standards.

Next step: Logic Telecom can help select a safe pilot, design tools and integrations, and establish audit and acceptance criteria.