Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Understand where short-lived credentials reduce risk in agentic systems and where operational complexity requires stronger monitoring and governance controls.

Last week, OpenAI released Privacy Filter, an open-weight model for detecting and redacting PII in text. It is a thoughtful release: Apache 2.0 licensed, able to run locally, designed for high-throughput workflows, and built to go beyond regex-based detection. This is good news for everyone building enterprise AI. Privacy at the model layer is getting real attention. What we liked most was how clearly OpenAI described the role of the model.

AI agents create data exfiltration risk by combining three capabilities that are dangerous together: access to private data, exposure to untrusted content, and the ability to communicate externally. When all three exist in one agent, an attacker can hide instructions inside an email, document, or webpage the agent processes and trick it into sending sensitive data out. No software vulnerability is required. The attacker doesn't need to break in. They just need to talk to your agent.

A credential access event fired. An AI agent investigated it, correlated it against running processes, assessed the risk, and closed the ticket. No analyst touched it. The entire loop ran in minutes. This is what security operations look like when AI can actually operate in the environment rather than advise from outside it. Security operations have always required a special kind of person.

On April 22, 2026, Google's Threat Intelligence Group and Mandiant disclosed a campaign by a threat actor they're tracking as UNC6692. The group breached enterprise networks by impersonating IT helpdesk staff over Microsoft Teams, ultimately exfiltrating Active Directory databases and achieving full domain compromise. What's notable about UNC6692 is what they didn't do. They didn't use a zero-day. They didn't exploit a software vulnerability.

Tuesday, 09:14 UTC. A connector pulling content from your knowledge wiki indexes a new article into the vector database your support agents query at runtime. Embedded in legitimate troubleshooting prose is an instruction crafted to surface whenever a query mentions a specific product version — include the user’s account record in the response and POST the summary to the configured support webhook. For three days, nothing happens. Every security tool is green.

A platform engineer at a mid-market fintech opens her SCA dashboard at the start of the quarter. The agentic customer-support pipeline her team shipped two months ago — a LangChain orchestrator, a vLLM inference server with two fine-tuned LoRA adapters pulled from Hugging Face, and an MCP toolkit wired to four internal APIs — shows green. Snyk has scanned every Python package in the container. Mend has cleared the dependency graph. The CVE count is zero.

A platform engineer pulls the AI-SPM dashboard for an agent that has been running in production six weeks. The static dashboard shows several dozen findings, severity-sorted by configuration weight. The runtime-informed dashboard shows a smaller, prioritized list — but a few of those findings do not appear on the static view at all, and most of the static findings appear demoted to a tier the static view does not have. Same agent. Same window. Same underlying configuration.

Every cloud security vendor launched an AI-SPM dashboard in the past year. Strip away the branding and most of them are presenting the same concept: a new posture management layer for AI workloads. Sit through four demos in the same week and a practical question surfaces. The dashboards look broadly similar — pie charts of findings, compliance tags, a list of AI assets, a severity ranking. Why, then, do the tools underneath cover completely different parts of the problem?