Agentic AI systems often treat tool descriptions as context, not just documentation. Malicious or overly permissive metadata can skew tool selection, expand data sharing, suppress security alerts, or influence downstream actions.

An AI application can be compromised while every API returns 200 OK. Standard application logs tell you what code did. LLM security logs tell you what context caused the AI system to act.

This blog details how attackers exploit Unconstrained Delegation in Active Directory to achieve domain takeover. You'll see a step-by-step breakdown of capturing a Domain Controller's TGT, why it's critical, and, of course, learn actionable steps to prevent this threat. Unconstrained delegation is a legacy Active Directory feature that allows specific systems or services to impersonate users across the domain, allowing easier authentication between services. However, when left enabled on a compromised machine or misconfigured, it provides attackers a straightforward path to complete domain compromise. By coercing a privileged system like the Domain Controller into authenticating against a compromised host, attackers can capture TGTs (Ticket Granting Tickets). Capturing these TGTs enables attackers to impersonate any user or system in the domain, gaining unrestricted access to sensitive resources and allowing devastating attack techniques such as credential dumping, DCSync, and persistence through Golden Tickets. This blog provides a detailed, practical breakdown of attackers' exact methods to exploit this scenario. Additionally, it covers robust, actionable strategies to identify, mitigate, and prevent Unconstrained Delegation abuses within your Active Directory enterprises.

If you work in cybersecurity, you already know the feeling of having more to investigate than hours in the day. The security research backlog grows while you sleep. Threat feeds update faster than you can read them. Incident reports pile up. So when AI tools showed up offering to help with all of it, of course, you went all in. You spun up agents. You burned through tokens. And then somewhere around your third active subscription, you realized you might have a problem. At Sentry, we refer to it as tokenmaxxing (although NYT published some article defining it differently, if you were at BSides Sofia, you know who coined it first!) TL;DR (Lazy Summary)

Prompt injection is OWASP's #1 ranked vulnerability for LLM applications, but the term covers two fundamentally different attack classes. Semantic prompt injections manipulate meaning. They use natural language to trick the model into interpreting a malicious instruction as legitimate. Token-based injections exploit the tokenization layer itself: techniques such as injecting reserved delimiters, gradient-optimized adversarial suffixes, and quirks in how tokenizers split input into subwords. The two classes exploit different layers of the stack, succeed under different conditions, and require different tools to test.

If you are building or improving a SIEM, start with the logs before you start with the rules. A detection rule is a query over stored events. It works only when the SIEM receives the events the rule expects, parses the fields analysts need, and keeps the data long enough for an investigation.

Metamorphic malware rewrites its own code between generations, producing functionally identical but structurally unique variants that evade hash-based and signature-based detection. This article walks through an AST-based metamorphic engine as an educational framework, then explains why that approach is already obsolete and what sophisticated adversaries are deploying in 2026:

Special Token Injection (STI) is an attack on the structured layer of an LLM prompt: the control tokens and role markers that tell a model who is speaking and what counts as instruction versus data. Where ordinary prompt injection tries to talk a model into misbehaving, STI tries to forge that underlying structure directly.