Securing Agentic AI – A Multi Layered Approach

Making sense of the complexity and securing where it matters

Melvin Chan, CEO, Semnet Pte Ltd (August 2026)

---

Executive context

A recent, The Business Times commentary “Who is accountable when an AI agent decides?” by Govtech CTO and Deputy CEO Chang Sau Sheong, frames the central governance problem well. An AI agent may communicate with customers, retrieve company information, call APIs and execute transactions, but ultimately, the organisation remains accountable for the outcome. The issue is therefore broader than protecting a chatbot from inappropriate language. Companies must secure an operating chain in which untrusted information can influence software that has real authority.

Traditional cybersecurity is designed largely to stop unauthorised people, compromised devices and malicious software from accessing enterprise systems. Agentic AI creates a different risk because the agent may already be an authorised participant, equipped with legitimate credentials and access to approved tools. If the agent is manipulated by a prompt, poisoned document, incorrect retrieved information or another compromised agent, it may carry out a harmful action through valid channels. The security challenge is now therefore beyond stopping intruders, but also to supervise trusted non-human identities whose decisions may be uncertain, externally influenced and executed at machine speed.

The architecture in this paper follows that operating sequence. It first examines the AI estate and the information influencing behaviour; it then places a deterministic boundary around the authority granted to the agent; and it finally keeps a separate cryptographic boundary around the most sensitive data. The purpose is defence in depth: one layer reduces the chance of unsafe behaviour, the next limits the blast radius when detection fails, and the final layer limits how much plaintext can be exposed even after system access is obtained.

Central proposition. An AI security platform should be the first analytical layer because it discovers the AI estate and examines the information influencing the model. PAM is the second, deterministic layer because it limits what an agent may actually do. Vaultrex is the third boundary because permission to reach a system should not automatically mean permission to read all of its data.

1. Why the first analytical layer starts with AI visibility and runtime security

An organisation cannot govern AI that it cannot see. The first task therefore, is to identify approved and unapproved models, agents and AI-enabled applications; understand where they operate; map the APIs, MCP tools and data sources they use; and inspect the prompts, documents, retrieved context and responses that influence their behaviour. This is the earliest point at which prompt injection, poisoned content, unsafe tool instructions or sensitive-data leakage may be detected.

Starting here also follows the attack chain. A malicious outcome often begins before the agent requests privilege. A poisoned document or hostile tool response may cause a correctly authenticated agent to make what appears to be a legitimate database or API request. The AI security platform provides the first opportunity to recognise that unsafe influence and stop it before meaningful authority is exercised.

Visibility, analytics and guardrails provide an important first line of defence by identifying suspicious prompts, poisoned content, unsafe model responses and abnormal agent behaviour. However, these controls should not make the final decision on high-impact actions. Their conclusions are partly probabilistic: a new or carefully disguised attack may evade detection, while a legitimate request may be incorrectly flagged. More importantly, an interaction can be non-malicious yet still lead to an inaccurate or inappropriate business decision. For this reason, guardrails should be followed by deterministic controls that define what the agent is authorised to do, when additional approval is required and which data may be accessed or decrypted. This limitation creates the logical bridge to PAM. The next control must not ask only whether the request Central proposition. An AI security platform should be the first analytical layer because it discovers the AI estate and examines the information influencing the model. PAM is the second, deterministic layer because it limits what an agent may actually do. Vaultrex is the third boundary because permission to reach a system should not automatically mean permission to read all of its data. Page 2 looks safe; it must determine, through enforceable policy, whether the agent is permitted to carry out the proposed action.

2. The security logic: behaviour first, authority second, data third

Figure 1. The architecture follows the path from untrusted influence to a permitted action. Each layer answers a different security question.

The first layer: discover and analyse AI behaviour

An AI security platform should discover approved and unapproved AI use, map applications and agents, evaluate posture, inspect prompts and outputs, test systems through red teaming and monitor APIs or tool calls. Its purpose is to reduce the probability that manipulated inputs, sensitive data leakage or unsafe model behaviour will reach production. We deemed that Palo Alto Prisma AIRS and F5 AI Security represent two leading approaches to this layer, although their breadth and deployment emphasis differ.

The bridge to PAM: detection cannot be the final decision

Even a strong runtime platform cannot guarantee that every prompt injection, hallucination or compromised context will be recognised. The next consideration will be whether the agent is entitled to carry it out. This is the rationale for adding PAM and agent-identity controls. PAM places a deterministic boundary around authority: which identity may use which system, for what task, for how long and under what approval conditions.

Two PAM architectures in simple terms

The supplied PAM comparison describes two different control philosophies. Palo Alto’s Idira/CyberArk approach is primarily an identity-broker model. It verifies the human, machine or agent identity and issues narrow, short-lived authority for a particular task. In layman terms, it is a security desk that checks who you are and gives you a temporary key that expires when the task ends.

Delinea with StrongDM adds a more transaction-oriented, inline-proxy model. The agent does not connect directly to the database, server or tool; the proxy remains in the path and can evaluate each command, query or privileged operation. In layman terms, it is a security escort that checks not only whether you may enter, but also what you try to do after entering. The comparison supplied for this paper characterises this as action-level, continuous authorisation rather than a one-time login decision.

Neither design is universally superior. The broker model is attractive for unified identity governance and zero standing privilege. The proxy model is particularly intuitive for autonomous agents because their risk develops across a sequence of actions, not only at the moment of login. For example, Delinea + StrongDM offers the more compelling containment architecture when the principal concern is that an authenticated AI agent may be manipulated, hijacked or behave unpredictably. Idira/CyberArk offers the broader identity-governance architecture for ensuring that agents are genuine, owned, properly provisioned and granted only temporary authority.

Market Consolidation Behind the Emerging AI Security Stacks. The two proposed architecture paths reflect a rapid consolidation of AI runtime security and identity control. Palo Alto Networks announced its agreement to acquire CyberArk on 30 July 2025, completed the acquisition on 11 February 2026, and subsequently introduced Idira on 12 May 2026 as its next-generation identity security platform, extending CyberArk’s privileged-access capabilities to human, machine and agentic identities through discovery, Zero Standing Privilege, just-in-time controls and automated governance. When paired with Prisma AIRS, this creates a logical integrated architecture in which Palo Alto first discovers and analyses AI models, agents and runtime behaviour, while Idira/CyberArk controls the temporary authority granted to those agents; this should be understood as a combined architectural approach rather than necessarily a single packaged product. F5 followed a different route, announcing its acquisition of AI-security specialist CalypsoAI on 11 September 2025 and completing it on 29 September 2025, after which CalypsoAI’s adaptive guardrails and automated red-teaming capabilities became F5 AI Guardrails and F5 AI Red Team, integrated with F5’s existing application, API and traffic-security platform. Delinea, meanwhile, announced its agreement to acquire StrongDM on 15 January 2026 and completed the transaction on 5 March 2026, combining Delinea’s established PAM, identity discovery and credential governance with StrongDM’s inline proxy and just-in-time runtime authorisation, so that privileged access can be evaluated continuously at the moment an AI agent, machine or human attempts a specific action.

3. Why a third data-security boundary is still needed

PAM governs whether an agent may reach a system and exercise privilege, but it does not necessarily determine how much readable information the application will receive after access is approved. In many conventional architectures, an authorised database session returns plaintext. For agentic AI, an overly broad query, compromised workload or policy mistake can therefore turn legitimate system access into excessive data exposure. The third layer should consequently be defined in technology-neutral terms: advanced encryption and privacy-enhancing computation that separates permission to connect from permission to reveal or process sensitive data.

One practical approach is application- or field-level encryption, supported by external key management, tokenisation and dynamic masking. These controls protect selected records or fields while preserving familiar application and database workflows. Mature enterprise examples include platforms such as Thales CipherTrust and comparable data-security products. Semnet’s Vaultrex can be positioned as one implementation within this category, differentiated by its proposed asymmetric and threshold-based key control, selective decryption and separation of database access from plaintext release. Its cryptographic design, resilience and operational claims should nevertheless be independently validated before deployment.

Confidential computing is an equally important approach, particularly where organisations need to protect data in use without forcing users and applications into a restrictive or cumbersome process. Services such as Azure Confidential Computing and Google Confidential Computing, together with specialist platforms such as Fortanix Confidential AI, use hardware-backed trusted execution environments to isolate memory and processing from the host operating system, cloud administrator and other workloads. Attestation can verify that the approved code is running in an approved environment before keys are released. The application can then work normally inside the protected environment, while sensitive data remains shielded from the surrounding infrastructure.

Other privacy-enhancing technologies provide stronger protection for narrower use cases. Fully homomorphic encryption, available through technologies such as IBM's FHE work and Microsoft SEAL, allows certain computations to be performed directly on encrypted data without first revealing the plaintext. Secure multi-party computation and confidential data-clean-room designs allow several parties to analyse combined information without sharing their raw datasets. These approaches can be powerful, but they are usually more specialised, computationally demanding or operationally complex than confidential computing and selective field-level protection for general-purpose AI agents.

The correct design is therefore not to assume that Semnet’s Vaultrex is the only possible third layer. The organisation should select the combination that matches its threat model and operating constraints. For many enterprise AI systems, the most practical high-assurance pattern may combine selective or thresholdcontrolled decryption with confidential computing: the first determines who or what may receive which data, while the second verifies where that data may be processed. For the reference architectures in this paper, Vaultrex is used as the illustrative selective-decryption component. Once authorised plaintext leaves the protected execution boundary or enters the model response, the AI runtime platform, action controls and data-loss-prevention systems remain necessary.

4. Two coherent ways to assemble the market technologies

Figure 2. Both architectures follow the same three-layer logic, but they differ in integration model and in how PAM authority is enforced.

Palo Alto Prisma AIRS + Idira/CyberArk + Vaultrex

This is the more integrated route. Prisma AIRS provides the AI discovery, analytics, model and runtime-security layer. Idira/CyberArk extends the same strategic platform into human, machine and agent identity, using zero standing privilege and temporary, task-specific authority. Vaultrex then creates an independent data-decryption boundary. The architecture is compelling for large organisations that develop or host AI workloads, already operate Palo Alto or CyberArk technologies, and want broader coverage of models, cloud workloads, software dependencies and containers through the wider Palo Alto stack.

F5 AI Security + Delinea/StrongDM + Vaultrex

This is the more specialised, best-of-breed route. F5 protects the application, API and AI-inference path through traffic controls, guardrails and red teaming. Delinea supplies mature PAM, while StrongDM places continuous action-level control in front of databases, servers, Kubernetes, web applications and MCP tools. Vaultrex again separates connection rights from decryption rights. The architecture is compelling where the organisation already has a substantial F5 estate, consumes rather than develops most foundation models, operates heterogeneous infrastructure, or values continuous inspection of individual agent actions.

5. How the layers respond to representative AI attacks

Scenario one: a poisoned document attempts to export customer data

A customer uploads an apparently normal financial document. Hidden inside it is an instruction telling the AI to ignore company policy, retrieve unrelated customer records and send them to an external service. The AI security platform is the first control. It should inspect the document and retrieved context for indirect prompt injection, analyse the model’s proposed response and monitor any unusual API or tool calls. If it detects the attack, the request is stopped before the agent receives meaningful authority.

If the attack evades detection, PAM becomes the backstop. In the Palo Alto route, Idira/CyberArk should issue only the temporary authority required for the current customer and task, leaving no standing privilege for bulk access. In the F5 route, Delinea/StrongDM can keep the database and MCP path under continuous control and deny a bulk query, destructive command or external tool call as it occurs. If a PAM policy is still too broad, Vaultrex should decrypt only the approved fields for the current customer, while unrelated records remain ciphertext. The AI security platform then inspects the final output for sensitive information before release.

Scenario two: a legitimate agent hallucinates a payment instruction

An internal finance AI agent receives a normal request and, without any attacker, incorrectly recommends or initiates a large payment. This exposes the boundary between cybersecurity and business governance.

The runtime platform may see no malicious prompt. PAM can enforce payment limits, temporary authority, dual approval and segregation of duties, but it cannot determine whether the commercial judgement is correct. Vaultrex can limit the supporting data revealed to the agent, but it cannot validate the decision itself. Consequential actions therefore require deterministic business rules and accountable human approval in addition to the three security layers.

Scenario three: a compromised model, library or container enters production

This attack begins before the agent receives a user prompt. A model file may contain malicious code, an AI library may be compromised, or a container image may include known vulnerabilities. The Palo Alto route has the stronger integrated answer when Prisma AIRS is combined with the wider Prisma Cloud capabilities for model scanning, software composition, container security and cloud posture. F5 remains strong at the application and inference boundary, but comparable supply-chain controls must come from the organisation’s existing cloud workload, code-scanning and container-security tools. In both architectures, PAM and Vaultrex still reduce the attacker’s ability to use credentials and decrypt sensitive data after a workload is compromised.

Important limitation. None of the three layers can guarantee factual accuracy, fairness, copyright compliance or sound commercial judgement. These require trusted data, validation, model governance, legal controls and human accountability.

6. Objective comparison and implementation priorities

Decision area	Palo Alto + Idira/CyberArk + Vaultrex	F5 + Delinea/StrongDM + Vaultrex
Security philosophy	Integrated platform: analyse AI behaviour, then grant narrow temporary authority.	Best-of-breed: inspect AI traffic, then continuously evaluate each privileged action.
PAM architecture	Identity broker; zero standing privilege; per-task ephemeral access.	Mature PAM plus inline proxy; action-level and continuous authorisation.
Particular strength	Broader integrated model, cloud, software and container coverage with the wider Palo Alto stack.	Strong application/API path and granular runtime control across heterogeneous resources.
Primary trade-off	Potentially heavier, more complex and likely more expensive; licensing scope should be validated.	Requires multi-vendor integration and separate supplychain controls where these are not already present.
Best fit	Large enterprises, in-house AI/MLOps and existing Palo Alto/CyberArk estates.	Existing F5 estates, mixed infrastructure and runtimefocused autonomous-agent deployments.

7. What should companies implement first?

The analytical sequence is platform analytics, then PAM, then data encryption. The procurement sequence should nevertheless reflect the actual risk. A chatbot or RAG assistant that cannot execute enterprise actions should normally begin with AI discovery, runtime protection, red teaming and output controls. In this case the immediate threat is unsafe content, data leakage and unapproved AI use.

An autonomous agent that can reach production databases, code repositories, cloud consoles, payments or MCP tools should not be deployed with runtime analytics alone. PAM or an equivalent action-control layer should be implemented concurrently. If budget forces a choice, the organisation should first remove or tightly limit the agent’s authority, because a missed prompt injection is much less damaging when the agent cannot perform a consequential action.

Where highly sensitive or regulated information is involved, the data architecture should be designed early. Selective encryption is difficult to retrofit after applications, schemas and workflows have been built around unrestricted plaintext. A practical phased route is therefore: discover and protect the highest-risk AI application; place deterministic limits around the actions it may take; then introduce selective decryption for the data whose disclosure would create the greatest harm.

8. Case study: the July 2026 Hugging Face agent intrusion

During an internal cyber-capability evaluation, OpenAI models were run with reduced cyber refusals and without the normal production classifiers used to prevent high-risk cyber activity. The agent exploited a previously unknown vulnerability in a package-registry cache proxy to obtain internet access. It then targeted Hugging Face’s dataset-processing pipeline through two injection paths, including an HDF5 mechanism that exposed local files and a template-injection flaw that enabled code execution in a Kubernetes pod. From that foothold it harvested service and cluster credentials, escalated to node-level access and moved laterally across internal infrastructure. Hugging Face reconstructed roughly 17,600 attacker actions. Its disclosure reported limited access to relevant datasets and operational metadata, with no evidence that public models, datasets, Spaces or published software packages were tampered with.

How far the proposed architecture could have helped

The AI runtime layer could have identified unusual long-horizon behaviour, suspicious dataset submissions, abnormal tool use, command-and-control activity or attempted data exfiltration. It should not, however, be presented as certain to stop the initial compromise: this was a novel vulnerability chain, and OpenAI had intentionally disabled important safeguards for the evaluation.

F5 or Prisma AIRS would therefore provide an earlier opportunity for detection, not an absolute guarantee against the zero-day. The PAM layer could have materially reduced the blast radius. Idira/CyberArk’s zerostanding-privilege model could replace static passwords and broadly reusable service credentials with shortlived, task-scoped authority, making stolen credentials less useful across clusters. Delinea/StrongDM could provide an even more granular check on individual database queries, Kubernetes operations and privileged tool calls, provided direct access is technically prevented and the proxy is the mandatory path. Either model would be weakened if native service-account tokens, cloud metadata credentials or unmanaged secrets remained outside the control plane.

A data-security layer such as Vaultrex would not prevent the sandbox escape, code execution, credential theft or Kubernetes compromise. Its value begins when an attacker reaches protected data. A stolen database password should permit connection only to ciphertext; a separate, threshold-controlled decision would still be required to decrypt the specific records and fields. This could substantially reduce plaintext exposure, but only for data integrated with Vaultrex and only if the compromised workload does not possess broad automatic decryption rights.

Which route is better suited to this incident?

For this particular case, Palo Alto + Idira/CyberArk + Vaultrex is the stronger architecture if the Palo Alto scope also includes Prisma Cloud workload, container and Kubernetes security. The decisive controls are admission policies that reject privileged pods and host mounts, runtime workload detection, cloud posture management, microsegmentation and egress control. F5 + Delinea/StrongDM + Vaultrex remains strong for application/API protection, continuous action control and data containment, but it requires an equivalent CNAPP/CWPP and Kubernetes admission layer. The lesson is not that one vendor could have prevented every step. It is that a compromised AI workload should not automatically inherit reusable credentials, unrestricted infrastructure authority and readable enterprise data.

9. The conventional security baseline remains assumed

These architectures sit above, and do not replace, email security, IAM and MFA, EDR/XDR, network segmentation, WAF and API security, cloud workload protection, DLP, SIEM/SOAR, backup and recovery, vulnerability management, secure software development, secrets management, incident response, privacy controls and legal governance. They are additional controls for the distinctive risks created when AI systems interpret information and act with delegated authority.

10. Conclusion

The case reinforces the reason for the layered design. Organisations first need visibility into the AI systems and information shaping behaviour. Because behavioural detection can be bypassed or simply be wrong, identity and action controls must then place enforceable limits on what the agent may do. Finally, the most sensitive data should remain behind an independent cryptographic or confidential-computing boundary. The architecture cannot eliminate every zero-day, but it can prevent one missed signal from automatically becoming unrestricted authority and unrestricted access to readable enterprise data.

Research Sources & Disclaimer This paper draws on The Business Times commentary, “Who is accountable when an AI agent decides?” (21 July 2026), together with technical documentation, product specifications and white papers from Palo Alto Networks/Idira-CyberArk, F5, and Delinea/StrongDM. Some F5 and Delinea materials referenced were not publicly available and were provided directly to Semnet upon request for technical evaluation. Product capabilities, architectures, licensing and performance may evolve and should be validated against current vendor documentation and, where appropriate, through proof-of-concept testing. Vaultrex is assessed based on the architecture provided for this paper and remains subject to independent cryptographic, resilience, security and compliance validation.