|
By Shauli Rozen
Most teams buy detection on a single number. The datasheet says “millisecond detection,” the proof-of-concept fires the instant a test payload lands, and the box gets checked. Then a real AI agent incident runs in production, and the postmortem shows the attack completed its objective well before anyone contained it, even though the alert, technically, fired in milliseconds. The number was real. It just measured the wrong thing.
|
By Yossi Ben Naim
The first time a security team needs an AI agent audit trail is usually 72 hours after the agent has already done something it shouldn’t have. Detection fires. Someone pulls every relevant log from the SIEM (Kubernetes audit, container runtime, cloud audit) and three hours in realizes the events that actually matter were never written. Which prompt triggered the tool call. Which parameters the agent passed. Which output left the cluster.
|
By Shauli Rozen
Every AI-SPM tool runs posture and detection with a single arrow: runtime evidence flowing back to rank posture findings. The load-bearing direction runs the opposite way, and almost nothing runs it — posture flowing forward to tell the detection layer what an attack even looks like.
|
By Ben Hirschberg
A security team running agents in production can already list the ways those agents get attacked: prompt injection, memory poisoning, tool abuse, model tampering, agent-to-agent coercion. The list is not the problem. The problem is that a security architect can recite all five and still not know which ones their detection stack will catch, because the way the field catalogs these attacks says nothing about whether the attack is catchable.
|
By Shauli Rozen
The early stages of an AI agent attack are silent. The poisoning, the hijacked intent, the reconnaissance: none of it executes, so none of it produces a runtime signal, and the kill-chain instinct every security team runs on says exactly the wrong thing here: break the earliest link. There is no early link to break. You cannot detect a stage that emits nothing.
|
By Yossi Ben Naim
A compromised agent doesn’t make a single call it isn’t allowed to make. It queries a table it’s authorized to read, calls a tool it’s authorized to use, sends to a domain that’s on the allowlist. Every call is legal. The attack is in the values it passes, and your tool-call log records all of it as a clean day’s work. A tool call has two layers. Almost every tool you run reads the first one: the call itself: which tool, in what order, at what rate.
|
By Ben Hirschberg
Your AI agent just did something it has never done. It called a tool that is not in its usual set, or it opened a connection to a destination you do not recognize, or its output came back subtly wrong. So you do what anyone does: you search for what a compromised agent looks like, and you find a checklist. Unusual tool usage. Unexpected data access. Out-of-context responses. Elevated resource consumption.
|
By Yossi Ben Naim
An AI agent moving laterally through a Kubernetes cluster does not look like an intrusion. There is no foreign process, no exploit, no dropped binary — just the agent using the identity, network routes, and tools it was handed at deployment to reach targets it was technically allowed to touch. That is the entire problem. The controls you run were built to catch an outsider pivoting from host to host.
|
By Shauli Rozen
If you’re weighing open source against commercial tools for detecting attacks on your AI agents, you’re probably trying to answer a single question. Can we build this ourselves, or should we buy it? It’s a fair question, and the existing content on it isn’t much help. Most comparisons line up tools side by side and tally features. That tells you which tool is better at one slice of the problem. It doesn’t tell you whether you have a working detection program.
|
By Ben Hirschberg
Most enterprise AI agent governance programs publish policies at the bottom three rungs of a runtime enforceability ladder while their architecture diagrams claim rung four. Almost no program reaches rung five, the only rung that produces evidence an auditor cannot dispute. The mismatch shows up in the audit committee meeting. The CISO walks in with the NIST AI RMF mapping, the AUP, the model cards, and the vendor risk assessments for every third-party API the agents call.
|
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.
- 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.