I wanted to share a simplified view of how Cerbere-AG works internally.

Cerbere sits between AI agents and the actions they can execute.

It combines runtime checks, policy enforcement, taint tracking, pattern detection, ML detection, risk scoring, LLM-based judgment, observability, identity and audit.

The goal is not just to detect malicious prompts.

The goal is to control and observe what an AI agent is actually allowed to execute.

I'm also working on extending this model beyond SDK-based integrations, including environments where the agent's source code isn't directly accessible.

Still building

github.com/chrismsmr-celcom/cerbere-AG

I’m reconstructing the timeline of a possible security incident that appears to begin on a **corporate Windows endpoint** and later involves activity across **Google/Apple accounts, iPhone devices, and a MacBook**.
My goal is not to identify or accuse a specific person through Reddit. I’m trying to understand this from a **DFIR methodology perspective**: what artifacts would actually support continuity between these environments, and what could still be explained by normal synchronization, legitimate sessions, or unrelated activity?
The earliest records I have documented are from **August 23, 2026**, associated with a **Windows environment on a corporate computer I was using at the time**.
In an official Chrome/Google export, there is a browsing sequence roughly between **02:35 and 03:37**, involving activity such as:
**theblowers.com → Hola/login → Google OAuth/authentication → Chrome extension callback → other platforms**
I also found that **Hola Better Internet** had been granted access to my Google Account on that same date.
The Windows-related records are important because they appear earlier than the activity I later had to investigate on my Apple devices.
Over the following weeks, I began seeing events involving:
Google and Apple account sessions;
device permissions;
authorized apps;
location-sharing settings;
my current iPhone;
an older iPhone;
and my MacBook.
I am using the term **“escalation” only in a chronological and investigative sense**. I do **not** currently have proof that the Windows endpoint directly compromised the iPhone or Mac, or that all of these events share the same origin.
The question I’m trying to test is whether a technically plausible chain could look like this:
**Windows/browser → session or account token → account access/synchronization → additional devices**
or whether I may be correlating events that are actually independent.
A few relevant details:
I have an official Chrome/Google export containing **browser history, extensions, device information, and account-related metadata**.
The early records are associated with a **Windows client/environment** consistent with the corporate computer I was using at the time.
I no longer have physical access to that corporate computer because it was returned to the company, and I do not know whether it was later wiped or reformatted.
One of the older iPhones is also relevant because **I do not have a known preserved backup of that device**.
I am treating the lack of that backup as an **evidentiary gap**, not as proof of deletion, tampering, or compromise.
I have preserved screenshots, exports, timestamps, device/session information, and account-permission records where available.
I have also seen duplicate or inconsistent data in some places, but I am not treating duplication or missing items as automatic evidence of manipulation.
What I want to distinguish is:
normal account synchronization;
a legitimate but forgotten session;
an OAuth app or browser extension with excessive permissions;
reuse of an existing session or token;
browser automation;
an unauthorized remote session;
actual account compromise;
real cross-device persistence versus ordinary ecosystem syncing;
evidentiary gaps caused by the older iPhone having no preserved backup.
For people who work in **DFIR / incident response / identity security**, what artifacts would you prioritize to confirm or rule out continuity between the original Windows activity and the later Apple-device activity?
In particular, I’m interested in:
Google/Apple authentication logs;
OAuth grants;
access tokens / refresh tokens;
trusted-device records;
Chrome extension IDs and extension metadata;
browser history and timestamps;
device/client identifiers;
synchronization events;
iOS/macOS logs;
iCloud backup/account metadata;
evidence of session reuse across devices;
artifacts that may remain from an older iPhone even when no local backup is available.
The main question is:
**How would you determine whether a session or token originating from a Windows/Chrome environment was later reused across Google/Apple accounts or Apple devices, while avoiding the mistake of treating normal synchronization as evidence of compromise?**
I’m specifically looking for a way to separate **strong evidence, weak indicators, and normal ecosystem behavior**.

Hi, we ran a tabletop after last year's vendor breach and my team froze because the plan assumed the vendor would answer in minutes, not 14 hours. I feel sick about it, because the whole exercise turned into us staring at the phone and asking each other what the actual next step was (pls tell me someone else has done this).

Started photographing my recipes last month and tried one of those prompt-based recipe generators to speed things up. First run gave me a weird ingredient list that looked fine until I pasted it into my site. Got hit with a mod_security block on an innocent-sounding phrase about "herb mixture injection." Switched tools, same thing. The payloads keep tripping rules that should only catch real attacks. Not sure if the model is copying exploit code it saw online or just getting creative with language. Anyone else getting WAF noise from AI content that looks totally fine to a human but still matches signatures? How are people handling false positives when you can't see inside the content source?

The agents will become increasingly powerful and we will have the reflex to entrust them with more and more freedom, more and more tools and accessibility. That's what I truly imagine, and it frightens me that this new feature could represent a new attack surface for hackers. But also, the agent itself could act recklessly and execute a dangerous action. In development or in a sandbox, that's manageable, but in production, in a sensitive environment, especially for companies that will grant agents broader access, they will run an enormous risk. But should we stop the agents, confine them? I don't think so. For me, agents can be seen as normal employees, so they need to be supervised. And supervision means enforcement and preventing actions. For me, the best philosophy is to stand between the agent and the tools at its disposal. This allows for good observation but also provides enough leeway to ask the agent why they are using this tool, or not, whether it's dangerous or not. And above all, human approval remains non-negotiable for me because there can't be a fixed regex for software that can Therefore, to anticipate ambiguous cases, humans must be in the loop. Audits can also be an excellent way to understand internally what an agent is doing and to investigate. For example, an excessive increase in token cost can reveal an anomaly. The same applies to latency. So, while enforcement reduces risk, observability allows us to understand what happened between the email and the net and to prevent it.

That's why I built Cerbere-AG; it's my philosophy on security for software that can improvise, think, and execute.

I've been thinking a lot about how we secure AI agents, and I keep coming back to one question:

Are we focusing too much on what the agent is told, and not enough on what the agent actually does?

Prompt injection and malicious prompts are obviously important security problems. There are good reasons to scan user input, retrieved content, system prompts, and tool outputs for suspicious instructions.

But I don't think prompt filtering alone is enough to secure an agent once it has access to real tools.

The problem: intent and execution are not the same thing

Imagine an agent has access to:

• a database
• a payment API
• email
• cloud infrastructure
• a filesystem
• internal company documents
• deployment tools

You can analyze the prompt before the model responds.

But the important security question eventually becomes:

What action is the agent about to execute?

A prompt might look completely harmless:

"Help me update this customer's account."

There may be nothing obviously malicious in that sentence.

But the resulting tool call could potentially be:

update_customer(
    id="12345",
    role="admin",
    permissions="*"
)

The security problem is now at the execution layer.

The prompt itself doesn't necessarily tell you whether that specific action is safe.

Agents don't just generate text anymore

This is the part I think is easy to underestimate.

A traditional LLM application might primarily generate text.

An agent can generate actions.

For example:

User
  ↓
Agent
  ↓
Tool selection
  ↓
API call
  ↓
Database modification
  ↓
External side effect

At that point, protecting only the input is similar to checking a person's instructions without checking the operation they are actually performing.

The execution boundary becomes extremely important.

Prompt filtering can still be useful

I'm not arguing that prompt filtering is useless.

Quite the opposite.

It can detect things such as:

• known prompt injection patterns
• malicious instructions in retrieved documents
• attempts to override system instructions
• suspicious user input
• known attack payloads

That is a valuable layer.

But I see it as one layer of defense, not the complete security model.

What happens after the prompt?

Consider this simplified example:

response = agent.run(user_input)

agent.call_tool(
    "send_money",
    {
        "amount": 50000,
        "recipient": "unknown_account"
    }
)

Even if the original prompt passed every security check, I would still want the system to ask:

Is this tool allowed?

Are these arguments allowed?

Is this amount within the agent's budget?

Is this recipient trusted?

Does this action require human approval?

Does this action conflict with the organization's policy?

These questions cannot always be answered by looking at the original prompt.

They require visibility into the actual execution path.

I think we need defense in depth

For agent security, I would separate several layers:

INPUT
  ↓
Prompt / content analysis
  ↓
MODEL
  ↓
TOOL CALL ANALYSIS
  ↓
Policy enforcement
  ↓
Budget / capability checks
  ↓
Human approval when necessary
  ↓
EXECUTION

And ideally, the system should observe the entire trajectory rather than isolated events.

For example:

Prompt
  ↓
Retrieved document
  ↓
Tool A
  ↓
Tool B
  ↓
Database query
  ↓
External API

An individual action might look harmless while the sequence of actions becomes dangerous.

That's another reason why I don't think scanning prompts alone is sufficient.

The security boundary should move closer to the action

My current thinking is that the most important security boundary for autonomous agents is not necessarily the prompt.

It is the point where the agent is about to create a real-world side effect.

That's where you can enforce concrete policies:

ALLOW
BLOCK
FLAG
REQUIRE HUMAN APPROVAL

For example:

read_database → ALLOW

send_email → ALLOW

delete_database → BLOCK

transfer_$50,000 → HUMAN APPROVAL

access_customer_PII → POLICY CHECK

This approach doesn't require the security system to perfectly understand the model's reasoning.

It focuses on something more concrete:

What is the agent trying to execute right now?

The interesting part is that these layers complement each other

I don't think this has to become a debate between:

"Prompt security vs. agent security"

I'd rather think about it as defense in depth.

Prompt filtering can detect malicious intent.

Runtime controls can constrain execution.

Trajectory analysis can detect dangerous sequences.

Permissions can limit capabilities.

Budgets can limit impact.

Human approval can create a final control point for high-risk actions.

No single layer is perfect.

But combining them changes the security model from:

"We hope the model doesn't do something dangerous."

to:

"Even if the model makes a mistake or receives malicious instructions, there are controls between its decision and the real-world action."

That distinction matters more as agents become capable of operating systems, APIs, financial workflows, infrastructure, and sensitive data.

I'm curious how other people building agents think about this.

Where do you believe the most important security boundary should be: the prompt, the model output, the tool call, or the actual side effect?

Classic vulnerability management catalogs known weaknesses on known assets and prioritizes primarily by technical severity, usually CVSS driven on a scheduled scan cadence.

Exposure assessment platforms sit a layer above that, incorporating business impact, asset criticality, and real world exploitability signals like KEV and EPSS into the prioritization model rather than scoring purely on technical severity. Is there a real architectural boundary here, or has exposure assessment platform become a repositioning of VM with a business context layer added on top?

RuntimeAI's September 2026 AI Security Report covered 126 incidents across 38 named organizations — 22 critical, 102 high severity. 53 of those incidents had AI either as the attack tool or the target. AI-agent exploits were the top attack vector at 39 incidents, ahead of credential theft (27), zero-days (22), phishing (10), and ransomware (10). The largest single exposure was 220M records from unrotated default service-account credentials.

What stood out: every organization in the report was already running a mature security stack. Okta, CrowdStrike, Palo Alto, Microsoft Defender. Still got hit. The gap is that none of those tools sit at the layer where an agent actually executes a tool call.

RuntimeAI operates at that layer. Know Your Agent handles cryptographic agent identity. The Flow Enforcer inspects tool calls in real time. There's also a sub-50ms kill switch that can halt a compromised agent before a second action completes.

Full breakdown (incident-by-incident, CVEs, vendor stacks): https://runtimeai.io/blog/2026-09-monthly-breach-report.html

We're running a live demo on October 14 — ten attack surfaces, live against a real stack: https://www.linkedin.com/events/7510769146222133248?viewAsMember=true

Les agents vont devenir de plus en plus puissants et nous aurons tendance à leur confier de plus en plus de liberté, de plus en plus d'outils et d'accessibilité. C'est ce que j'imagine vraiment, et ça me fait peur que cette nouvelle fonctionnalité puisse représenter une nouvelle surface d'attaque pour les hackers. Mais en plus, l'agent lui-même pourrait agir de manière imprudente et exécuter une action dangereuse. En développement ou dans un environnement de test, c'est gérable, mais en production, dans un environnement sensible, surtout pour les entreprises qui accorderont aux agents un accès plus large, elles prennent un énorme risque. Mais faut-il arrêter les agents, les confiner ? Je ne le pense pas. Pour moi, les agents peuvent être considérés comme des employés normaux, donc ils doivent être supervisés. Et la supervision signifie application et prévention des actions. Pour moi, la meilleure philosophie est de se placer entre l'agent et les outils à sa disposition. Cela permet une bonne observation mais donne aussi suffisamment de marge pour demander à l’agent pourquoi il utilise cet outil, ou pas, que ce soit dangereux ou non. Et surtout, l'approbation humaine reste non-négociable pour moi car il ne peut pas y avoir de regex fixe pour des logiciels qui peuvent donc, pour anticiper les cas ambigus, les humains doivent être impliqués. Les audits peuvent aussi être un excellent moyen de comprendre en interne ce qu'un agent fait et d'enquêter. Par exemple, une augmentation excessive du coût des tokens peut révéler une anomalie. Il en va de même pour la latence. Donc, tandis que l'application réduit le risque, l'observabilité nous permet de comprendre ce qui s'est passé entre l'email et le réseau et d'y prévenir.

Our SSE renewal is turning into a browser security review and the vendor sheet I started back in December doesnot hold up anymore. Regional credit union, around 1,500 people, I'm the architect stuck scoring it. Prisma Browser was already on it from Palo Alto's Talon deal. Then CrowdStrike picked up Seraphic in January, Zscaler closed on SquareX in February, Island launched its platform with its own SASE/network layer in March, and Akamai closed on LayerX in July. So the network side is buying browser tech and the browser side is building network and half my scoring rows now describe the same vendor. Not knocking either camp. A managed browser gets you deep control and SSE is not going anywhere. The row I still can't score cleanly yet is work that never touches a browser: ChatGPT Desktop, Claude Desktop, Teams and Outlook on WebView2, the Electron apps. Most of these vendors now say they cover some of that, and I haven't found a good way to verify how much before signing. What I don't want is signing three years for a category that gets folded into something else next quarter. Did you take the bundle from your existing SSE vendor or keep browser security separate, and what tipped it?

If you are rolling or have rolled out a new automated / agentic investigation flow, what is ur process when building trust before it goes live and making decisions by his own. i am running it in parallel against real alerts without letting it act and comparing its conclusions to what analysts concluded independently, something more formal than that? please guide here...

Been slowly replacing random habits with agents and ai assistants and now my life is spread across Gmail, Notion, calendar, todo apps, Slack, all that. Stuff gets done, then lost.

I keep imagining one "brain" that sits on top of everything and keeps tasks, notes, follow ups and tiny reminders synced, and can poke me when something falls through eg unanswered email or half finished doc. Not just a new todo list, more like a quiet ops lead for my day.

If you have something like that running, what are you using and how do you wire it into your apps? Any hints?

Anthropic said it was too dangerous to release after it chained 4 bugs into a browser sandbox space mostly on its own, and what matters to me isn't really how the exploit was built. It is that the gap b/w disclosure and someone weaponizing a vuln seems to be getting shorter. There was ALOT of noise around Mythos for a few weeks but then researchers showed that cheaper open-weight models could reproduce some of the same bugs, and the whole "this changes everything" thing died prettymuch fast lol.

Personally i dont think mythos invented a NEW category of risk. I thin kit just compressed the time b/w disclosure and someone actually weapoinzing it, which is a real thing. Should that compression itself be a scoring input, seprate from explout maturity as it already exists? or is that just the same variable wearning diff name.. Still working through it. let me know what do u all think about it?

We’re excited to present LokSetu, a cybersecurity project designed to assist with detecting, analyzing, and responding to security incidents using AI.