|
By Yossi Ben Naim
The board wants to know which AI agent risk to fund first, and a likelihood score cannot answer it. No incident survey gives base rates for agents on your architecture, and an agent can take a different path on the same input. What a CISO can estimate is what each risk would cost to recover from: the work to detect it, scope it, revoke the authority it used, and prove what happened. Ranked on that cost, unexpected code execution drops toward the bottom.
|
By Shauli Rozen
The agent that worries you is authorized. It holds a service account you provisioned, calls tools you approved, and reaches destinations someone signed off on. Zero trust asks two questions at every decision point, who is this and what are they allowed to do, and an agent redirected by trusted input answers both correctly every time. For a person those questions fire at a session boundary, where context gets re-checked. An agent on Kubernetes has no such boundary.
|
By Ben Hirschberg
An agent’s logs are written by the agent. Every framework log, trace span and tool-call record that an agentic AI security platform ingests comes from the process being watched, or from a gateway that sees only what that process routes through it. When a trusted prompt coerces an agent into misusing a permission it already holds, the record shows a normal tool call, because from inside the process it was one. Running more analysis on that record returns the same answer faster.
|
By Ben Hirschberg
NIST has published no AI agent authorization standard, and nothing in its February 2026 draft gives an auditor a control to test. What the NCCoE did publish is more useful to a CISO with an audit on the calendar: five areas of interest that read like an assessor’s question list. Together they ask which agent acted, on whose behalf, under what authority, and with what record. A Kubernetes cluster has a primitive it can point to for each area.
|
By Shauli Rozen
Identity governance cannot tell you which AI agent did something. It records which identity is allowed what. In a cluster, one service account often serves several workloads, and every pod is replaced at the next rollout. As a result, the permission record and the behavior record point at different objects. Detection and investigation need a unit of attribution. The Deployment is the right one. It stays stable across restarts and replicas and changes only when someone ships a rollout.
|
By Shauli Rozen
Two of the three layers of agentic AI security already have an owner in your organization, and the third has none. Identity falls to IAM and interaction falls to AppSec, because the controls at both layers extend products those teams already run. The behaviour layer covers what the agent does on the infrastructure once it is running, and it sits between a platform team with no security mandate and a SOC with no sense of what normal looks like for an agent. That gap is where a coerced agent works.
|
By Yossi Ben Naim
A browser agent in your cluster opens a supplier portal, screenshots it, and clicks somewhere the task never called for. The page looks exactly like the page the supplier serves, and to the person who checks it later, it still does. The classifier in front of the agent returned nothing, because the instruction that produced the click does not exist.
|
By Shauli Rozen
The blast radius of a prompt injection against your coding assistant was set weeks ago, by whoever built the dev environment image. Same assistant, same model, same injected sentence: on a laptop it collects every repository, SSH key and cloud login the developer holds; on a provisioned dev box it collects an organization token plus whatever the image left behind; on a CI runner it collects a deployment credential and a network path to production. Three environments, three incidents, one payload.
|
By Yossi Ben Naim
Every action in your agent-incident runbook operates on the agent. The payload of a RAG prompt injection sits in the index. You can kill the pod, rotate the credential and revoke the session, and each of those stops this workload from doing that thing again. None of them touch the chunk that caused it.
|
By Ben Hirschberg
Tool output is untrusted because your own systems produce it. That is the part of the OWASP guidance that never makes it into a deployment. The label goes on web pages and email bodies, where an outsider obviously wrote the text. It never goes on the ticket store, the CRM, or the repo, because those are yours. The attacker does not care whose system it is. He cares which field takes free text: the ticket body, the opportunity note, the PR description.
|
By ITProTV
With the short week for the Thanksgiving holiday in the US, the Technado team decided to have a little fun by looking back at some of the dumbest tech headlines from 2019. Romanian witches online, flat-earthers, and fake food for virtual dogs - what a time to be alive. Then, Shauli Rozen joined all the way from Israel to talk about a zero-trust environment in DevOps. IT skills & certification training that’s effective & engaging. Binge-worthy learning for IT teams & individuals with 4000+ hours of on-demand video courses led by top-rated trainers. New content added daily.
- September 2026 (11)
- August 2026 (4)
- July 2026 (1)
- June 2026 (3)
- May 2026 (25)
- April 2026 (30)
- March 2026 (31)
- February 2026 (13)
- January 2026 (14)
- December 2025 (2)
- November 2025 (3)
- October 2025 (1)
- September 2025 (2)
- August 2025 (2)
- July 2025 (2)
- June 2025 (3)
- May 2025 (3)
- April 2025 (7)
- March 2025 (6)
- February 2025 (7)
- January 2025 (6)
- December 2024 (9)
- November 2024 (3)
- October 2024 (3)
- September 2024 (6)
- August 2024 (5)
- July 2024 (4)
- June 2024 (4)
- May 2024 (2)
- April 2024 (3)
- March 2024 (4)
- February 2024 (4)
- January 2024 (7)
- December 2023 (5)
- November 2023 (4)
- October 2023 (3)
- September 2023 (5)
- August 2023 (6)
- July 2023 (4)
- June 2023 (4)
- May 2023 (4)
- April 2023 (2)
- March 2023 (4)
- February 2023 (3)
- January 2023 (2)
- December 2022 (4)
- November 2022 (5)
- October 2022 (3)
- September 2022 (4)
- August 2022 (2)
- July 2022 (4)
- June 2022 (6)
- May 2022 (1)
- April 2022 (4)
- March 2022 (4)
- February 2022 (4)
- January 2022 (4)
- December 2021 (6)
- November 2021 (1)
- October 2021 (1)
- September 2021 (2)
- August 2021 (2)
- July 2021 (3)
- April 2021 (3)
- February 2021 (1)
- December 2020 (1)
- October 2020 (1)
- September 2020 (1)
- July 2020 (2)
- June 2020 (1)
- March 2020 (1)
- February 2020 (1)
- January 2020 (4)
- December 2019 (2)
ARMO closes the gap between development and security, giving development, DevOps, and DevSecOps the flexibility and ease to ensure high grade security and data protection no matter the environment – cloud native, hybrid, or legacy.
ARMO is driving a paradigm shift in the way companies protect their cloud native and hybrid environments. We help companies move from a “close-the-hole-in-the-bucket” model, installing firewalls, defining access control lists, etc. to a streamlined DevOps- and DevSecOps led model in which environments are deployed with inherent zero-trust.
Security at the Speed of DevOps:
- Runtime workload identity and protection: Identifies workloads based on application code analysis, creating cryptographic signatures based on Code DNA to prevent unauthorized code from running in the environment to access and exfiltrate protected data. The patent-pending technology signs and validates workloads in runtime throughout the entire workload lifecycle.
- Transparent data encryption: Transparent data encryption – keyless encryption – robustly and uniformly encrypts and protects files, objects, and properties, requiring no application changes, service downtime, or impact on functionality. It eases the adoption of encryption by removing the complexity of key management and providing an out-of-the-box solution for key protection in use, key rotations, and disaster recover procedures.
- Identity-based communication tunneling: Transparent communication tunneling ensures only authorized and validated applications and services can communicate. Even if attackers steal valid access credentials, they are useless because the malicious code will be unsigned. Create API access polices to build identity-based policies and enforce correct workload behaviors.
- Application-specific secret protection: Application-specific protection of secrets ensures cryptographic binding between continuously validated specific workload identities and their confidential data, delivering complete protection against access by unauthorized applications.
- Visibility & compliance: Visibility and compliance monitoring provide granular details about workloads and running environments, including individual processes, file names and locations, open listening ports, actual connections, mapped volumes, opened files, process privilege levels, connections to external services, and more. Alerts can be used for continuous compliance verification.
Bringing Together Run-Time Workload And Data Protection To Seamlessly Establish Identity Based, Zero-Trust Service-To-Service Control Planes.