From Development tool to the New Perimeter of Trust

The incorporation of generative artificial intelligence (AI) transforms how organizations develop software and automate tasks. Agentic systems deepen this change, because an agent not only generates text, but also interprets goals, uses tools, and executes actions on behalf of a user.

This offers productivity opportunities but modifies a key premise of computer security. It is no longer enough to protect internal systems; it is also necessary to control which external resources can influence an agent’s actions, something that deserves special attention in tax administrations that manage sensitive information and critical state services.

Imagine someone without training in agentic security[1] using an AI agent to incorporate a framework into an application. The agent consults documentation, accesses a repository, identifies dependencies, and installs components. What happens when a tool capable of executing actions in an institutional environment receives part of its instructions from external sources that the organization does not fully control?

The risk does not require convincing the model to “ignore its instructions.” It is enough for the agent to correctly execute a legitimate task in which one of its components is compromised, whether it is an installation script, a dependency, or an external service. For the user, it is a normal installation, and for an attacker, an opportunity to enter the environment.

When the Supply Chain Becomes Frantic

Software supply chain security is not a new problem, and what changes with AI agents is how you interact with them. An agent can discover dependencies, execute commands, and install components, and the greater its autonomy and permissions, the greater the impact of an incorrect decision or manipulation. The Open Worldwide Application Security Project (OWASP), an international reference in software security, calls this combination of excessive functionality, permissions, and autonomy “Excessive Agency,” and recommends limiting tools and their permissions, avoiding open interfaces such as arbitrary command execution.[2]

The problem becomes delicate when the agent accesses external sources and internal resources simultaneously, acting as a bridge between them.

It is also not just about the developers’ conduct. Anyone can use an agent to create an application or integrate services without knowing the dependencies or permissions involved. Even if the person, the tool, and the task are legitimate, the combination can create a risk. Therefore, the institutional response should not be limited to asking users to “be careful,” but should incorporate security into the architecture, access policies, and governance of these tools.

The Risk Appears when the Perimeter is Crossed

The U.S. National Institute of Standards and Technology (NIST) calls AI agent hijacking an indirect form of prompt injection in which an attacker introduces malicious instructions within data that the agent processes, and in its evaluations observed AI agents being induced to download and execute programs or exfiltrate information.[3] The separation between untrusted data and trusted instructions thus becomes a security boundary, because any document or repository can end up influencing the agent.

Even without direct manipulation of the model, a compromised component can be part of an apparently legitimate procedure. Therefore, the institutional question should not be limited to “Can we trust this agent?”, but should include what it can execute, what resources and credentials it accesses, what information it can send outside the organization, and what happens if one of the resources it consumes is compromised.

What Could This Mean for a Tax Administration?

Once a threat gains a foothold within an institutional environment, its impact is no longer limited to the team where it began. Based on existing architecture, permissions, and segmentation, an attacker could attempt to reach internal repositories, integration and deployment systems, secrets, application programming interfaces (APIs), or other network segments.

In a tax administration, these environments can be found close to, directly or indirectly, systems that process taxpayer information, declarations, payments, records, audits, or digital services. This concerns information protected by tax secrecy or tax confidentiality, the confidentiality of which sustains taxpayer trust, and records whose integrity has direct legal and collection consequences, such as a tax current account, a refund, or an ex officio determination cannot be altered without leaving a verifiable trail.

This does not mean that the use of AI agents implies a vulnerability of this type in itself. It means that the security architecture must consider the possibility of an agent tool becoming a connection point between external software and data and highly critical internal resources. In the tax context, this translates into specific controls.

The first is the limitation of access to data. By default, any agent’s access to tax systems should be read-only. An agent used to develop or test applications does not need to connect to production databases with taxpayer information but should operate in separate environments with anonymized or synthetic data. When a legitimate task requires real information, such as the analysis of statements or support for oversight, that access should be limited to the strictly necessary data and granted through temporary credentials specific to the agent, never inherited from an official with broad permissions.[4]

The second is the separation between analysis and action. Operations that affect a taxpayer’s situation, such as recording a transaction in their current account, issuing a notification, or approving a refund, should not be handled by an autonomous agent but should require human approval and adhere to the same authorization and segregation of duties circuits as are demanded from public officials.

The third is traceability. Many administrations already record which official consulted which taxpayer and for what reason, as a safeguard of fiscal secrecy. That standard must be extended to AI agents, so that each query and each action is recorded in a tamper-proof log that identifies the agent, the person operating it, the task that originated the access, and the data involved. Without that attribution, unauthorized access through an agent would be indistinguishable from legitimate access.

The fourth is the control of information output. Since exfiltration is among the scenarios evaluated by NIST, environments where AI agents with access to tax data operate should restrict outbound traffic to authorized destinations and monitor anomalous patterns, such as mass queries about taxpayers or submissions to unforeseen external services.

Training, governance, and continuous auditing

None of this implies prohibiting these tools but rather accompanying their adoption with a governance model based on three elements.

First, training. Users must understand that an agent capable of executing actions or interacting with institutional resources is not a chatbot, but a technological component with operational capacity.

Second, governance. The administration needs to know what agent tools are used, who uses them, with what permissions, and on which taxpayer systems and data.

Third, continuous auditing. The permissions, integrations, models, and extensions of these tools must be periodically re-evaluated, along with the review of access logs.

Security must accompany the entire lifecycle: assess → authorize → limit → monitor → audit → reassess.

A new conception of the perimeter

The adoption of AI agents does not eliminate traditional cybersecurity principles, such as least privilege, segmentation, secrets management, dependency control, and environment separation, but rather makes them more important. What is new is that the context and the tools that feed an agent are also part of the security surface.

Therefore, the challenge for tax administrations is not to prevent innovation, but to prevent it from inadvertently building new bridges to their most critical assets. If an agent can read, decide, and execute within an institutional environment, it must also be considered part of the security perimeter.

In the age of AI agents, protecting infrastructure no longer means just controlling who gets in. It also means controlling what can enter, what can be executed, and what capacity for action a tool gets once it is inside.

Notes:

[1] OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications for 2026, December 9, 2025.

[2] OWASP GenAI Security Project. LLM03:2026 Excessive Agency. OWASP Top 10 for LLM Applications 2026, August 2026.

[3] NIST, Center for AI Standards and Innovation (CAISI). Technical Blog: Strengthening AI Agent Hijacking Evaluations, January 17, 2025.

[4] OWASP Cheat Sheet Series. AI Agent Security Cheat Sheet.

12 total views, 12 views today