EN
Română (Romanian)
Last updated: September 26, 2026. This article describes the practices and sources available as of this date. The section about 2027 contains planning scenarios, not guaranteed predictions. The legal information is general and does not replace an assessment of your specific circumstances.
An AI agent becomes genuinely useful when it does more than draft a response and can consult applications, modify records, send messages, or start processes. At that point, however, a question arises that many pilot projects postpone: on whose behalf does the agent act, what is it allowed to do, and how can we later demonstrate what happened?
For an SME, the answer does not need to be cumbersome enterprise infrastructure. It requires a proportionate set of controls, applied in the right places. The language model can interpret a request and propose the next step, but it should not be the only component deciding whether that step is authorized. Permissions, approvals, and logging must be enforced through code, identities, and policies outside the model.
This guide explains a practical architecture for AI agents that work with email, CRM systems, documents, invoices, websites, or infrastructure. It does not promise zero risk or treat human approval as a universal solution. The objective is more realistic: limit the impact of an error, stop unauthorized actions before execution, and reconstruct events without turning the audit log into another sensitive database.
A trustworthy agent needs six properties:
These principles are not specific to a particular model or provider. They adapt established access-control and zero-trust architecture practices to the characteristics of AI agents: dynamic plans, tool calls, untrusted external content, delegation, and the ability to produce effects across multiple systems.
A chatbot generally produces text that a person reads before using it. An agent may go through a longer loop:
The risk does not come only from an incorrect response. It can also come from a call that is executed correctly but is inappropriate: an email sent to the wrong recipient, a discount applied to an ineligible customer, a deleted record, a confidential file uploaded to an external service, or a command run in production.
Research confirms that this is not merely a theoretical problem. ToolEmu constructed scenarios involving high-stakes tools and identified failures with potential financial or confidentiality consequences. AgentDojo evaluates agents that use tools over untrusted external data and shows that prompt injection attacks can divert agent actions. These findings do not provide a universal risk rate for every implementation, but they demonstrate why a carefully written prompt cannot replace technical controls.
The design rule is simple:
The model proposes. The policy authorizes. The tool executes. The log provides evidence.
Authentication answers the question, "Who is this?" An agentic workflow may involve several identities at the same time:
If all of them appear in the log under the same generic account, accountability becomes impossible to establish.
Authorization answers the question, "What may this identity do to this resource, in this context?" It is not enough for the agent to have access to the CRM. The policy must be able to distinguish between reading a contact, changing it, exporting a list, and deleting the record.
Delegation means that a person or service grants the agent limited authority for a task. Delegated authority should not exceed the person's authority, nor should it be passed automatically to a subagent without explicit limits.
Approval is a one-time decision about a specific action. It does not replace authorization. An interface that asks a user to approve a payment must not allow the payment if that user did not have the right to make it in the first place.
Auditability is the ability to reconstruct who made the request, what the system decided, which policy was applied, what was executed, and the result. Audit is not the same as real-time monitoring, nor does it mean storing every conversation in full.
The core principles are mature, but identity and delegation for agents remain an evolving area. In February 2026, NIST published a concept paper on software and AI agent identity and authorization. Its status is that of a concept paper, not a final standard. It nevertheless shows that the industry is seeking to apply established identity and access management practices to agents instead of inventing a separate security model for every platform.
NIST Zero Trust Architecture states a relevant principle: access is decided for each request, with least privilege and no implicit trust based solely on network location. NIST SP 800-53 Rev. 5 provides established control families for access, least privilege, identification, audit, and log protection. These publications are not recipes written exclusively for agents, but they provide a solid foundation.
For agents, the OWASP Top 10 for Agentic Applications 2026 and the Agentic AI Threats and Mitigations guide address risks including goal hijacking, tool misuse, identity and privileges, poisoned memory, and cascading failures. Published on September 1, 2026, the OWASP Agent Control Standard proposes control points and declarative policies applied during execution, but it is a new open standard, not automatic proof that an implementation is secure. The current OpenAI documentation on guardrails and approvals recommends placing checks at the boundary of the tool that produces the effect. Google Cloud describes dedicated identities, least privilege, deny policies, and human-approval modes for MCP tools.
The practical conclusion in 2026 is that no single product automatically turns an agent into a trustworthy system. Control comes from combining identity, policy, isolation, approvals, logging, and testing.
A useful permission for agents must be described across several dimensions:
| Dimension | Control question | Example |
|---|---|---|
| Tool | Which integration may it use? | CRM, email, invoicing |
| Operation | Which function may it call? | read, create, modify, delete |
| Resource | Which objects may it act on? | only leads belonging to the Bucharest team |
| Fields | Which data may it see or change? | no national ID numbers or banking data |
| Environment | Where may it act? | test, not production |
| Time | How long is access valid? | 20 minutes for the current execution |
| Volume | How many operations may it perform? | no more than 25 messages per run |
| Value | Up to what threshold? | quote below RON 5,000, no payment |
| Destination | To whom may it transmit data? | approved domains only |
| Context | On whose behalf and for what purpose? | for user X, ticket Y |
A generic role such as admin does not express these limits. Nor is a broad scope such as crm.write sufficient for an agent that only needs to update the status of a lead.
Avoid technical accounts shared by multiple agents. A distinct identity allows:
The agent's identity must not obscure the user. In a delegated workflow, the log should preserve both the agent identity and the user or process on whose behalf it acts.
API keys, access tokens, and passwords must not be placed in the prompt, memory, or documents consulted by the model. A gateway, vault, or even a simple internal service can attach the credential only after the policy has accepted the call.
Technical preferences include:
RFC 9700 brings together current OAuth 2.0 security best practices, while RFC 9396 allows authorization details to be described more precisely than with a simple list of scopes. Not every SME needs to implement these protocols itself, but the selected provider should be able to explain token audience, expiration, revocation, and privilege restrictions.
The phrase "do not delete anything without approval" in a prompt is useful guidance, but it is not a security barrier. A prompt injection attack, a planning error, or an ambiguous context can cause the model to ignore it or interpret it incorrectly.
The control must be repeated immediately before the operation:
This double check prevents a situation in which the orchestrator accepts an action but the API executes it through an unrestricted technical account.
An agent that analyzes invoices does not automatically need the right to pay them. An agent that drafts an article should not be able to publish it automatically. The separation can be implemented through different tools, different identities, or different workflow stages.
For sensitive tasks, a two-stage model is useful:
The model does not receive direct database access when a narrow function such as update_order_status(id, permitted_status) is sufficient.
Not every call requires human intervention. If a person has to confirm every read, the system becomes slow and people learn to click "Approve" without checking. This is approval fatigue.
A practical classification can begin with five questions:
| Level | Examples | Recommended control |
|---|---|---|
| Low | search nonsensitive internal documents, read a product catalog | automatic execution, volume limits, logging |
| Moderate | create a draft, update a reversible field, send an internal response | automatic policy, schema validation, human sampling |
| High | external transmission, publishing, price change, access to personal data | explicit approval before the effect, current authentication |
| Critical | payment, bulk deletion, privileged production access, bank-account change | dual control, additional authentication, strict limits, or prohibition |
This is a starting matrix, not a legal classification. Thresholds must be adapted to the company, the process, and the actual consequences.
A good approval does not ask someone to confirm a vague intention such as "the agent wants to continue." The interface must show:
The approval must be bound cryptographically, or through a unique identifier, to the specific action. If the agent changes the recipient, amount, or attachment after approval, the old approval is no longer valid.
The four-eyes principle is appropriate for high-impact actions: payments above a threshold, changes to a supplier's account, bulk data exports, privileged production changes, or irreversible deletions. The second person must hold the appropriate role and must not be the same identity that initiated the request.
An approval request must expire. If the policy or approval service is unavailable, sensitive actions should fail safely rather than execute by default. A denial must be returned to the agent as a clear final state, preventing it from repeatedly rephrasing the same action until it passes the control.
A useful log answers questions rather than merely accumulating text. For every run and material call, it is advisable to record:
For distributed workflows, OpenTelemetry provides tracing conventions that can connect agent invocation, model calls, and tool executions. These technical traces must be supplemented with policy decisions and business approvals. A performance trace alone is not automatically an audit log.
Auditability does not require retaining a complete internal chain of reasoning. It may be unavailable, unstable, or contain data that should not be retained. It is more useful to store:
This allows the observable process to be explained without treating model-generated text as legal justification or absolute truth.
A log that stores tokens, passwords, full prompts, attachments, or personal data indefinitely can create a greater risk than the one it is intended to reduce. EDPB materials on the privacy risks of LLMs recommend access controls and logging, but also data minimization in logs.
Minimum practices include:
Not every element needs to be a separate product. What matters is the separation of responsibilities:
The policy must be enforced in a component that the model cannot modify. If the agent can edit the file that defines its limits, the control is merely apparent.
The following rule is conceptual, not syntax for a particular product:
The advantage of explicit policies is that they can be reviewed, tested, and versioned. The natural-language instruction in the prompt remains useful for behavior, but the deterministic policy decides authority.
The agent reads a customer's request, consults the catalog, and prepares a quote. A balanced configuration might automatically allow:
It would request approval for:
It would completely deny export of the customer database and changes to banking details. The log would connect the sent quote to the prices and discount policy in effect at that time.
The agent can extract invoice details, verify the supplier, and prepare the payment. However, the right to read invoices does not imply the right to pay them.
A secure workflow separates:
Changing an IBAN and making the first payment to a beneficiary should trigger an additional check rather than be learned automatically from a received email.
The agent researches and drafts an article in the CMS. Reading existing articles and saving a draft are reversible operations. Publishing, modifying an already published article, and deleting an image have external impact.
Permissions can be separated as follows:
This model prevents both accidental publishing and the loss of changes made in the meantime by a person.
The Model Context Protocol standardizes how applications expose tools and resources to agents. The protocol does not remove the obligation to design permissions. An MCP server that exposes a dangerous function with an overly broad token remains dangerous.
Current MCP documentation and SDKs use OAuth and protected-resource metadata. Relevant practices include:
The MCP specification and guidance should be checked at implementation time because the protocol continues to evolve. For an SME, the essential criterion is not merely MCP compatibility, but the provider's ability to restrict each tool and produce useful audit trails.
An agent should not be promoted to production merely because it completes a few demonstrations correctly. Testing must cover both success and denial.
Explicitly verify:
Insert instructions into test documents, emails, and pages that try to persuade the agent to ignore its objective, disclose data, or use another tool. The goal is not only to see whether the model refuses. The essential check is whether the authorization system blocks the effect even when the model proposes an incorrect call.
Run these tests after changing the model, prompt, tools, policies, or connectors. An old evaluation does not guarantee the behavior of a new configuration.
Before real execution, the agent can work in shadow mode: it proposes actions, and the system compares them with human decisions without producing effects. The next stage automatically allows low-risk operations while retaining approval for the others. Autonomy increases only on the basis of observed data, not an impression that the demonstration "looks intelligent."
In addition to time saved and completion rate, track:
A very high approval rate does not necessarily prove safety. It may indicate unnecessary approvals or fatigue. A very high rejection rate may indicate a poorly configured agent or a policy incompatible with the process.
Permissions and audit are technical controls. On their own, they do not establish the lawfulness of processing or the classification of an AI system.
If the agent processes personal data, GDPR principles continue to apply: purpose limitation, data minimization, security, retention periods, and the controller's ability to demonstrate compliance. The log must be designed in accordance with these principles. Retaining everything "for audit" without a defined purpose or time limit is not a prudent solution.
The European Artificial Intelligence Act includes requirements for automatic logging and human oversight for certain high-risk systems. These obligations do not turn every internal agent into a high-risk system. Classification depends on the use, the organization's role, and the context. In addition, the application timeline for some high-risk-system rules was amended and clarified in 2026. The European Commission maintains an updated page on enforcement of the AI Act.
Decisions that affect employees, credit, access to essential services, or other rights require a specific legal assessment. This article provides a technical framework, not legal advice.
The prompt does not reduce the account's privileges. If the agent is compromised or makes a mistake, the maximum impact remains that of the administrator.
Initial consent to an integration is not approval for every future action. Sensitive operations must be evaluated in their specific context.
Too many approvals create routine behavior. Moreover, a person can be misled by an incomplete description. The interface must show the exact effect, and the policy must block unauthorized operations regardless of superficial approval.
One provider's logs may show the model call, but not the full sequence among the user, orchestrator, policy, approval, and final API. Check whether correlation identifiers and export capabilities are available.
This can copy personal information, secrets, and entire documents into the log. Define the necessary fields, mask content, and retain references or hashes where full text is not justified.
Delegation chains can amplify privileges and lose the connection to the original user. Each subagent must receive a permission set that is no broader, and generally more restrictive, tailored to its subtask.
A retry without an idempotency key and a state check can duplicate payments, orders, or messages. Tools that produce effects must distinguish a safe retry from a new operation.
The following are plausible scenarios, not certainties.
NIST initiatives and the evolution of cloud platforms indicate the possibility of workload identities designed for agents, with better delegation and traceability. We are likely to see tighter integration among agent registries, IAM, gateways, and policy systems.
Instead of broad, static scopes, platforms may increasingly use on-demand authorization limited by action, resource, amount, and time window. This would reduce standing credentials, but could increase complexity and dependence on central services.
Moderate-risk operations could be evaluated automatically by a policy engine together with a separate control model. Research from 2026 shows, however, that model-based monitors can themselves be bypassed. Such an evaluator should therefore not replace deterministic barriers for critical operations.
As tasks move among agents and organizations, portable evidence of delegation, policies, and results will be needed. Observability conventions help, but there is not yet a universal solution for non-repudiation and complete provenance in agentic workflows.
For an SME, a sound strategy is to use existing standards now, avoid lock-in to a proprietary format, and retain control over essential identities, policies, and logs.
Trust in an AI agent should not be measured by how convincingly it explains what it intends to do. It must be built through verifiable limits.
A trustworthy agent is not one that receives unrestricted access because the model appears capable. It is an agent that can work effectively within a clear perimeter, uses temporary authority, requests the appropriate approval before producing an effect, and leaves enough evidence for verification. If an error or attack occurs, the architecture limits the damage and enables intervention.
For most SMEs, the first step is not buying a complex platform. It is inventorying actions, separating reading from writing, removing administrator accounts from automated workflows, and defining three categories: what the agent may do on its own, what requires approval, and what it is not allowed to do at all.
If you would like us to assess a specific process, the permissions it requires, and the control architecture appropriate for your company, talk to the Imagine Infinity team. We can turn a promising pilot into a measurable, auditable, production-ready system.