A standard prompt test would likely not have flagged that pattern. Refusing a malicious request says nothing about what the same model does when it can query a database, run code, reach cloud resources, and act through an account with real permissions.\u00a0<\/p>\n
READ MORE: That\u2019s the gap enterprises are walking into: a model can pass every safety test while the application around it still hands an attacker a way in.<\/p>\n Checking that a model gives a safe answer isn\u2019t the same as trusting the system you\u2019ve built around it \u2014 and the access you\u2019ve given it.<\/p>\n So the job for security teams is to limit what each agent can reach, tie its actions to a real identity, and retest every time the system around it changes.\u00a0<\/p>\n This reflects a subtle shift in focus\u2014moving away from merely testing static AI model outputs toward securing autonomous, agentic workflows operating in a live environment.<\/p>\n A safe answer can still trigger an unsafe action<\/p>\n Traditional security testing looks for a recognizable failure: an app that leaks data, an account with too many privileges, a malicious request slipping past a filter. AI workflows complicate that, because the risk often comes from combining several legitimate capabilities for a malicious effect.<\/p>\n If someone steals an employee\u2019s login information, they can access some systems right away. But they still need to search through files, figure out what\u2019s important, and plan their next steps. This takes time. AI speeds this up by linking information together and organizing the actions needed.<\/p>\n READ MORE: The model may be doing exactly what it was built to do. It summarizes documents accurately, pulls data through an authorized API, automates a routine task, and triggers no obvious alarm. Look at each action on its own, and nothing seems wrong. Look at them together, and the same actions could be helping someone steal data or set up a bigger attack.<\/p>\n For enterprises, that shifts attention to context and relationships: which identity started the action, what data guided it, which tools were called, and what happened next. A log showing an API call succeeded won\u2019t tell you whether that call was part of an abusive sequence.<\/p>\n Finding the line between helpful automation and misuse requires testing not just single features, but how they work together when someone tries to use them in harmful ways.<\/p>\n Too much access is a bigger risk<\/p>\n Security specialists have been warning about a problem bigger than a model giving a wrong answer: giving an agent too much freedom to act. OWASP\u2019s GenAI Security Project calls this \u201cexcessive agencyOpens a new window <\/a>,\u201d pointing to excessive functionality, permissions, and autonomy as the main sources of risk. An agent built to read documents shouldn\u2019t also be able to modify or delete them \u2014 so why give it those powers?<\/p>\n That question gets sharper once agents are connected to enterprise apps, and it\u2019s already showing up in the surveys. A March 2026 Cloud Security Alliance studyOpens a new window <\/a> \u2014 commissioned by identity-security vendor Aembit \u2014 found 68% of organizations couldn\u2019t clearly tell AI-agent activity apart from human actions, and 74% said their agents often get more access than they need. When agents borrow human credentials or shared accounts, it becomes hard to establish who did what \u2014 and whether the action was ever authorized.<\/p>\n In a recent interview with Help Net SecurityAriel Assaraf, CEO of Coralogix, draws the lineOpens a new window <\/a> between an agent that needs more context to do its job well and one that\u2019s getting too much context and expanding its attack surface. More context should improve what the agent knows, he says, not what it\u2019s allowed to do. \u201cSensitive or untrusted context should be separated from instructions, and access to information should never automatically grant permission to act on it. An agent knowing something and an agent being authorized to do something with that information are two different things,\u201d he says.<\/p>\n The new release gate for agents<\/p>\n As agents move from pilots into production, security teams face a familiar question, but with a new twist. How much testing is enough before a system gets access to real data and infrastructure?<\/p>\n A model passing its safety evaluations shouldn\u2019t clear that hurdle on its own. The application changes whenever developers add a tool, switch models, widen permissions, or connect another data source \u2014 and each change brings risks that weren\u2019t there when the system was first tested.\u00a0<\/p>\n Release approval has to be an ongoing process, not a one-time gate.<\/p>\n Before any agent goes live, organizations need evidence that it behaves safely under realistic conditions<\/a> and that its access matches its intended role. Failures have to be detected and contained. And every change to the app means retesting what the agent can now do.<\/p>\n Ananth Nag, general manager and vice president for Asia Pacific at Rubrik, puts identity first among the boundaries organizations should set for agents that trigger security or recovery actions. In a recent Q&A sessionOpens a new window <\/a>, with TNGlobal, he explained, \u00a0\u201cEvery agent action should be attributable to a specific human user and agent, with higher-risk actions requiring explicit approval. Traditional credentials, such as static API keys, were not designed for autonomous actors operating at machine speed.\u201d\u00a0<\/p>\n Scope is the second boundary, according to Nag. An agent that diagnosed a failed backup may need to read relevant data, but it shouldn\u2019t automatically be able to change retention policies or kick off a recovery. Access to sensitive data and high-impact actions should be narrowly scoped, with human approval where it counts \u2014 and every action documented, so teams can see what the agent accessed, proposed, and executed.<\/p>\n If all of this sounds like enterprise-scale work, it isn\u2019t. A five-person IT team running one agent against its ticketing system faces the same three questions as a Fortune 500 SOC: what can this agent reach, who does its actions get attributed to, and who signs off when it wants to do something risky. The difference is scale, not substance \u2014 and small teams have less room to absorb a mistake.<\/p>\n So start with the prompt test, but don\u2019t stop there. The real work is scoping what each agent can reach, tying its actions to a real identity, and rechecking every time the system around it changes. If you can\u2019t keep an agent inside defined limits when inputs are unexpected or part of the workflow fails, it needs narrower permissions, more safeguards, or more testing before it goes live.<\/p>\n For AI systems, true production readiness requires continuous verification of agent boundaries, scopes, and identities\u2014ensuring safety beyond the prompt.<\/p>\n Categories: AI<\/a>, Articles<\/a><\/p>\n Your Essential Daily Tech Brief<\/p>\n Sign up for the Spiceworks Newsletter and stay ahead with a curated mix of expert advice, technical tips, and the trending discussions your peers are having right now.<\/p>\n \n \uf00c\n <\/p>\n \n \uf071\n <\/p>\n \t\t \t\t\t\tWith nearly two decades of experience in B2B marketing, Priya creates content for business transformation enabled by cloud, data analytics, and AI. Her career journey spans GE Capital (turned Genpact in 2005), HCL Technologies, Cyient and a Delhi-based digital marketing company. She has led teams of writers and multimedia specialists to nurture campaigns for every stage of buyer journey, from awareness to advocacy. Her key areas of interest are FinOps, cybersecurity, and sustainability solutions that promote responsible innovation. Priya is also a dedicated animal rights advocate, serving homeless sentient beings.<\/p>\n","protected":false},"excerpt":{"rendered":"Most AI security testing asks one question: will the model refuse a malicious prompt? While that test is…\n","protected":false},"author":2,"featured_media":660012,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[85,46,296993,125],"class_list":["post-660011","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technology","tag-il","tag-israel","tag-securing-ai-agents","tag-technology"],"_links":{"self":[{"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/posts\/660011","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/comments?post=660011"}],"version-history":[{"count":0,"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/posts\/660011\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/media\/660012"}],"wp:attachment":[{"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/media?parent=660011"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/categories?post=660011"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.newsbeep.com\/il\/wp-json\/wp\/v2\/tags?post=660011"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n OneTrust tackles the agentic AI governance gap\u00a0<\/a><\/p>\n
\n The security risks SMEs face from unchecked AI agents<\/a><\/p>\n![\"img](\"https:\/\/www.newsbeep.com\/il\/wp-content\/uploads\/2026\/10\/img-loading-circle-1-final.gif\")
<\/p>\n![\"Priya](\"https:\/\/www.spiceworks.com\/wp-content\/uploads\/sites\/3\/2026\/07\/Priya-Singh-Headshot.jpeg?w=96\")
<\/p>\n