Book Consultation

Category: AI Security

  • AI Agents Need Identities Too: Extending Zero Trust to the Agentic Enterprise

    AI Agents Need Identities Too: Extending Zero Trust to the Agentic Enterprise

    For years, Zero Trust programs have focused on a familiar principle: never trust implicitly and continuously verify access based on identity, device, context, and risk.

    Agentic AI introduces a new participant into that architecture.

    An AI agent may read corporate data, invoke APIs, query databases, create tickets, modify cloud resources, communicate with external systems, or execute workflows on behalf of an employee. Unlike a conventional chatbot, the agent may perform several of these operations autonomously to accomplish a goal.

    This is quickly becoming an enterprise security issue rather than a theoretical AI concern.

    The next identity problem is not human

    Recent industry initiatives are extending AI security guidance toward practical runtime enforcement for agentic systems. At the same time, identity, cloud, endpoint, data, and SASE vendors are increasingly converging around a common idea: AI agents should be treated as first-class identities, with limited access, traceable delegated authority, continuous monitoring, and rapid containment.

    The direction is becoming clear: AI agents need to become part of the enterprise identity and Zero Trust architecture.

    Why traditional application security is not enough

    A traditional application normally operates through relatively predictable workflows. An AI agent is different because it can interpret instructions, make decisions, select tools and perform sequences of actions dynamically.

    That creates an important distinction between access and authority.

    An agent may legitimately have access to Microsoft 365, a CRM platform, ServiceNow and an internal database. That does not mean it should have unrestricted authority to perform every operation available through those systems.

    Consider an AI agent assisting a security operations team. It may reasonably need permission to retrieve an alert, obtain endpoint information, correlate identity activity, query threat intelligence, and prepare a recommended response. Allowing the same agent to disable accounts, isolate production servers or change firewall policy without additional authorization creates a very different risk profile.

    The security question changes from “Can this identity access the application?” to “What exactly is this agent authorized to do, under whose authority, for how long, and under what conditions?”

    Apply Zero Trust principles to agents

    Organizations do not necessarily need an entirely new security philosophy. Many existing Zero Trust principles translate directly to agentic AI.

    Give every agent an identity

    Production agents should not operate through anonymous access, shared service accounts or embedded long-lived credentials. Their activity should be attributable to a distinct workload or agent identity.

    Use least privilege at the action level

    Authorization should reflect the agent’s specific business purpose. Read, recommend, modify and execute are materially different privileges.

    Make delegation explicit

    When an agent acts for a user, the security architecture should preserve the relationship between the human identity, the agent and the resulting action. “The AI did it” cannot become an acceptable audit trail.

    Prefer temporary authority over standing privilege

    Where possible, provide scoped, task-specific and time-limited authorization rather than permanent access. This limits the blast radius if an agent is manipulated or behaves unexpectedly.

    Control tools as well as models

    The most consequential risk often is not what an LLM can say—it is what connected tools allow the agent to do. APIs, MCP servers, databases, SaaS connectors, automation platforms and privileged administrative interfaces become part of the AI attack surface.

    Monitor runtime behaviour

    Authentication alone is insufficient. Organizations should be able to detect unusual tool invocation, abnormal data access, unexpected delegation chains and actions outside the agent’s intended purpose.

    Design revocation and containment before deployment

    Security teams need the ability to terminate an agent session, revoke credentials, disable tools and isolate an agent without disrupting an entire application environment.

    Prompt injection becomes an authorization problem

    This architecture also changes how organizations should think about prompt injection.

    Preventing malicious instructions from reaching an AI model remains important, but assuming that every malicious prompt can be detected is unrealistic. A stronger architecture assumes that an agent may eventually receive or interpret an unsafe instruction and limits what happens next.

    If reading a malicious document can convince an agent to attempt an unauthorized action, the authorization layer should still prevent that action. That is classic defense in depth. The model should not be the final security enforcement point for its own privileges.

    Start with an Agent Access Matrix

    Before deploying a production AI agent, IFSEC recommends documenting at least five elements:

    Agent → Identity → Resource → Permitted Action → Authorization Context

    For example:

    SOC Investigation Agent → Agent Identity → Endpoint Platform → Retrieve telemetry → Analyst delegated session

SOC Investigation Agent → Agent Identity → Endpoint Platform → Isolate endpoint → Explicit elevated approval

    This simple exercise often exposes excessive permissions before sophisticated AI-security tooling is even introduced. It can then be expanded with data classification, logging requirements, approval thresholds, credential lifetime, network controls and automated response.

    The architecture matters more than the model

    Enterprise AI security discussions often concentrate on which model is being used or whether one model is safer than another. Those questions matter, but the larger architectural issue is increasingly what surrounds the model.

    Identity, authorization, data governance, API security, network enforcement, runtime monitoring and incident response determine how much damage an AI system can cause when something goes wrong.

    The organizations best positioned for agentic AI will therefore not be those attempting to eliminate every possible AI failure. They will be those designing environments in which an AI failure does not automatically become a security incident.

    That is fundamentally a Zero Trust objective.

  • Securing Enterprise AI: From Governance to AI Application and Agent Security

    Securing Enterprise AI: From Governance to AI Application and Agent Security

    Enterprise adoption of artificial intelligence is moving quickly from experimentation to production. Organizations are deploying Microsoft Copilot, ChatGPT, Claude, Gemini, GitHub Copilot, internally developed AI applications, and increasingly autonomous AI agents.

    The security challenge is no longer simply whether employees should be allowed to use AI. The more important question is how organizations can enable AI while maintaining control over sensitive data, identities, applications, infrastructure, and business processes.

    Traditional cybersecurity controls remain essential, but AI introduces additional attack paths and operational risks that require a broader security approach.

    AI Security Starts With Visibility

    Organizations cannot effectively secure AI usage they cannot see.

    Employees may use public AI services to summarize documents, analyze data, generate code, prepare customer communications, or perform research. Without appropriate visibility and controls, sensitive corporate information can unintentionally leave the organization.

    An effective AI security program should establish visibility into:

    • AI applications and services being used across the organization
    • users and devices accessing those services
    • sensitive information being submitted to AI platforms
    • sanctioned versus unsanctioned AI applications
    • internally developed AI applications, models, APIs, and agents
    • third-party integrations that connect AI systems to enterprise data

    This visibility provides the foundation for meaningful governance and technical controls.

    Governance Must Translate Into Technical Controls

    AI governance policies are important, but policies alone do not prevent data leakage or malicious activity.

    Organizations need to translate governance requirements into enforceable security controls.

    For example, a policy may prohibit employees from uploading confidential information to public AI services. Technical controls should then help identify sensitive data, restrict inappropriate uploads, monitor AI interactions, and provide different levels of access based on user, application, data classification, and business requirements.

    The objective should not necessarily be to block AI. It should be to enable appropriate AI usage while controlling risk.

    Protecting Enterprise Use of Generative AI

    Enterprise AI security must address both sanctioned and unsanctioned AI usage.

    Controls may include identity-based access, data loss prevention, application controls, browser security, endpoint visibility, logging, monitoring, and integration with existing security operations.

    Organizations should also understand how enterprise versions of AI services handle prompts, uploaded files, conversation history, retention, model training, and administrative controls.

    The security architecture should reflect the sensitivity of the information being processed rather than relying solely on the reputation of the AI provider.

    AI Applications Introduce New Attack Surfaces

    Organizations building their own AI-enabled applications face additional risks.

    AI applications often combine traditional application components with large language models, APIs, vector databases, retrieval systems, plugins, external data sources, and other enterprise services.

    This creates attack paths that may not exist in conventional applications.

    Examples include prompt injection, insecure output handling, sensitive information disclosure, excessive agency, improper access to data sources, model manipulation, insecure integrations, and abuse of AI-enabled business processes.

    Security therefore needs to be considered throughout the AI application lifecycle — from architecture and design through development, testing, deployment, and continuous monitoring.

    AI Agents Require Particular Attention

    AI agents represent an important evolution in enterprise AI because they can move beyond generating information and begin performing actions.

    An agent may retrieve information, interact with APIs, access databases, create or modify files, initiate workflows, communicate with other systems, or make decisions based on instructions and available context.

    That capability increases the potential business value of AI, but it also increases security risk.

    Organizations should carefully control agent identities, permissions, credentials, tools, accessible data, external communications, and the actions an agent is permitted to perform.

    The principle of least privilege becomes especially important. An AI agent should receive only the permissions necessary to perform its intended function.

    AI Red Teaming and Security Testing

    AI systems should be tested before organizations rely on them for sensitive or business-critical processes.

    Traditional penetration testing remains valuable for the underlying infrastructure and application components, but AI systems also require testing that reflects AI-specific behavior.

    AI security testing can evaluate areas such as prompt injection, system prompt exposure, sensitive data leakage, authorization bypass, unsafe tool invocation, manipulation of retrieval sources, agent behavior, and attempts to circumvent established controls.

    The objective is not simply to determine whether a model can produce an undesirable response. Testing should evaluate whether an attacker can use AI behavior to compromise enterprise data, systems, users, or business processes.

    AI Security Should Integrate With Existing Cybersecurity

    AI security should not become an isolated security program.

    Organizations already have significant investments in identity security, endpoint protection, network security, SASE/SSE, cloud security, data protection, application security, vulnerability management, logging, and security operations.

    A strong AI security architecture should determine how these existing controls can protect AI environments and where AI-specific capabilities are required.

    This reduces unnecessary technology duplication and allows AI security to become part of the broader enterprise security architecture.

    Building a Practical AI Security Roadmap

    Organizations do not need to solve every AI security problem at once.

    A practical approach begins by identifying how AI is currently being used, which business initiatives are planned, what sensitive information may be exposed, and which AI systems could create the greatest operational impact.

    From there, organizations can prioritize governance, architecture, technical controls, testing, monitoring, and implementation according to actual business risk.

    AI adoption will continue to accelerate. Organizations that establish security architecture early will be better positioned to adopt new AI capabilities without repeatedly redesigning controls after deployment.

    The objective is not to slow AI adoption.

    It is to make secure AI adoption possible at enterprise scale.