[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f4YCDe4x3NlXPKF9IQrqA5Ddp1gT6eZlyzr0xAhqSjJE":3},{"article":4,"iocs":39},{"id":5,"title":6,"slug":7,"summary":8,"ai_summary":9,"brief":10,"full_text":11,"url":12,"image_url":13,"published_at":14,"ingested_at":15,"relevance_score":16,"entities":17,"category_id":21,"category":22,"article_tags":26},"304f9cc9-0669-4c7f-b84a-8caeaef63cd7","Seeing AI Agents Is Not Enough. Security Teams Must Enforce What They Can Do","seeing-ai-agents-is-not-enough-security-teams-must-enforce-what-they-can-do-e06ab5","AI agent security is moving through a familiar maturity curve: adoption, then visibility, and finally, control. But what we've collectively discovered is that enforcing least privilege for AI agents is harder than we ever imagined. This is why there are so many approaches, from prompt filtering to identity-layer access controls. Where we've collectively landed is that understanding the intent of","Securing AI agents involves a maturity curve from adoption to control, but enforcing least privilege is challenging. Organizations must move beyond mere visibility to understand agent intent, manage their access, and ensure accountability. Traditional static access models are insufficient for dynamic AI agents, necessitating a focus on what agents should be allowed to do under specific conditions.","AI agent security requires enforcement of actions, not just visibility.","Seeing AI Agents Is Not Enough. Security Teams Must Enforce What They Can Do The Hacker NewsJul 24, 2026Enterprise Security \u002F AI Security AI agent security is moving through a familiar maturity curve: adoption, then visibility, and finally, control. But what we've collectively discovered is that enforcing least privilege for AI agents is harder than we ever imagined. This is why there are so many approaches, from prompt filtering to identity-layer access controls. Where we've collectively landed is that understanding the intent of AI agents is essential to securing them. It's not easy, but it's the only path forward. Organizations approach this challenge with different levels of sophistication. For many, the current goal is simply to find the AI agents already operating across the business. That is a necessary first step. AI agents are appearing in SaaS platforms, developer environments, cloud workflows, customer support systems, productivity tools, and internal applications. Some are sanctioned, and others are not. But discovery alone isn't useful. AI agents are not passive; they reason, plan, call tools, invoke APIs, access data, and take action without a human in the loop. The risk is not that an organization has too many agents. The risk is that those agents can operate across systems without consistent identity, intent, ownership, and enforcement. There are also different types of AI agents, each requiring a different approach to securing them. Recent guidance on the careful adoption of agentic AI services makes the point clear: agentic AI introduces privilege, authentication, accountability, design, and behavioral risks that security teams need to address before these systems become embedded in critical workflows. Visibility is the starting line, but enforcement is what matters. The Visibility Trap Most security programs begin with the question: \"What do we have?\" That made sense for cloud, SaaS, endpoints, identities, and vulnerabilities. It also makes sense for AI agents. But the risk of stopping at visibility alone for AI agents is greater than in every other environment in the list because of the speed with which AI agents are being created, what they have access to, and how they can be shared. An AI agent inventory that does not connect to enforcement becomes another static asset list. It may show that an agent exists, but it cannot tell you whether the agent's access is appropriate, its behavior matches its purpose, its owner remains accountable, or when its permissions should be revoked as conditions change. For AI agents, visibility without enforcement creates a dangerous kind of confidence, where it's easy to feel in control when the reality is far different. Why AI Agents Break Static Access Models Traditional access control assumes some level of predictability. Human Identity and Access Management has it the easiest, as each person has a job function. Non-human or machine identity management is more complex, but a service account still supports a defined workload. These assumptions are imperfect, but they gave security teams a foundation for roles, entitlements, approvals, access reviews, and periodic cleanup. AI agents are far from static. An agent is defined less by a fixed workflow and more by a goal. It may interpret instructions, call different tools, and adapt its actions based on context. Two agents with similar permissions may have a very different risk profile, depending on what each is trying to accomplish. Static access is not enough because AI agents are more likely to be used in ways not anticipated when access was granted. The issue is not always malicious behavior but ambiguity that poses a risk, such as a task that expands beyond its original purpose. The question security teams need to ask is not only \"what can this agent access?\" The more important question is: What should this agent be allowed to do, under these conditions, for this purpose? That is an enforcement question. Enforcement Starts With Better Understanding Effective AI agent enforcement cannot be bolted onto a basic, non-contextual inventory. Security teams need to correlate information across owners, consumers, identities, systems, permissions, and intent before they can define meaningful controls. That means understanding an agent across several dimensions: Ownership: Who owns the agent? (This can be more difficult than you may think.) Consumers: Who is using the agent? Identity: Which identities, tokens, secrets, OAuth grants, and service accounts does the agent use? Intent: What is the agent supposed to accomplish? Access: Which systems, applications, data stores, APIs, and infrastructure can it reach? Usage: What has the agent actually done, and how often? Origin: How was the agent created? Lifecycle: Is the agent active, dormant, or no longer tied to its original purpose? This is where many organizations struggle because agent context is scattered. Identity data lives in one place. Cloud permissions are somewhere else. SaaS integrations have their own models. Infrastructure as code can reveal intended deployment patterns, but that context is rarely correlated with the rest. Ownership may be obvious to the person who created the agent and invisible to everyone else. Without correlation, enforcement becomes guesswork. With correlation, security teams can begin defining rules that reflect how agents actually operate. From Remediation to Rules Many security tools equate enforcement with remediation. Something risky is found, and a playbook opens a ticket, removes access, disables an identity, or notifies an owner. That is useful, but it is not enough for agentic AI. AI agents need enforcement before, during, and after they take action. Security teams need to move from asking, \"What should be removed after risk is detected?\" to \"What should this agent be allowed to do in the first place?\" That shift moves enforcement from cleanup to control. Organizations can then define rules such as: A customer support agent can read ticket history, but cannot export customer data in bulk A code assistant can suggest changes, but cannot push to production without an approved workflow A cloud operations agent can inspect configuration drift, but cannot modify privileged roles A finance agent can generate reports, but cannot initiate payments or change vendor details A security agent can triage alerts, but cannot delete logs or suppress detections These rules cannot be managed effectively inside one AI platform at a time. Enterprises will use many agent platforms, SaaS-native agents, internal frameworks, cloud services, and developer tools. Each may have its own controls, logs, and permission models. Security teams need a consistent way to govern agents across that fragmented environment. That is why the next control plane for AI agents has to be identity-centric, context-aware, and platform-agnostic. The Role of Intent in Enforcement Identity answers who the agent is. Permissions answer what access exists. Intent answers why that access should be active. The intent dimension is essential. AI agent risk cannot be understood only by looking at whether an API call is technically permitted. Security teams need to evaluate whether an action aligns with the agent's approved purpose. Intent-based enforcement gives organizations a more precise control model. It allows security teams to move from broad, static permissions to conditional access based on purpose and context. That does not mean every action must be manually approved. It means high-risk actions should be constrained by the agent's role, owner, task, environment, and expected outcome. The OWASP Top 10 for Agentic Applications highlights risks such as identity and privilege abuse, tool misuse, insecure inter-agent communication, cascading failures, and rogue agents. These risks all point to the same conclusion: security controls must understand the agent's reason to act. A Singular Control Plane for Agentic AI A","https:\u002F\u002Fthehackernews.com\u002F2026\u002F07\u002Fseeing-ai-agents-is-not-enough-security.html","https:\u002F\u002Fblogger.googleusercontent.com\u002Fimg\u002Fb\u002FR29vZ2xl\u002FAVvXsEhrpwR_tXhzpbt7F1FuALLW8MYrTuwWibwuWjsRDROepxJKdbvSNlbcZLHbL54SmyG_Q_oYFTjI5fqkudKNtfJkg68jAz4STq0xXHEOXnMeOq7fxPz2UslZesQBy_pWKn3IKYNEbltVsjbZDypkqi56JOeznD5hcGEKO6yB-qS2l5cPHlcX0cli_WOHNGM\u002Fs1600\u002Fpixer.jpg","2026-07-24T11:30:00+00:00","2026-07-24T12:00:24.170249+00:00",7,[18],{"name":19,"type":20},"AI agents","technology","839da5c1-3c34-47e2-9499-f7201640e3ac",{"id":21,"icon":23,"name":24,"slug":25},null,"AI Security","ai-security",[27,32,34],{"category":28},{"id":29,"icon":23,"name":30,"slug":31},"2c8f44d4-b56e-47cf-9677-04f22c9ee78d","Identity & Access","identity-access",{"category":33},{"id":21,"icon":23,"name":24,"slug":25},{"category":35},{"id":36,"icon":23,"name":37,"slug":38},"e7b231c8-5f79-4465-8d38-1ef13aea5a14","Threat Intelligence","threat-intelligence",[]]