DEV Community: CyberMeshSec

Agentic AI — Autonomy With Guardrails

CyberMeshSec — Fri, 10 Jul 2026 14:29:18 +0000

Most people hear "agentic AI" and picture Skynet ordering pizza. The reality is less cinematic and more like a well-trained dog that knows which rooms it's allowed in.

I've spent the last few months pulling apart agent frameworks. Not reading whitepapers — actually running them, breaking them, watching where they fail. The pattern is consistent: the difference between an AI that's useful and one that's dangerous isn't the model. It's the boundary you draw around it.

An agent is just a loop. It thinks, acts, observes, and repeats. What makes it "agentic" is that it chooses its own next action. Nobody is clicking the buttons for it. And that's where things get messy.

The autonomy spectrum nobody talks about

There's this idea floating around that agents are binary — either a chatbot or fully autonomous. That's wrong. Autonomy is a dial, not a switch.

Think of it like driving assists. Level 1 is cruise control — the AI suggests, you confirm. Level 2 is lane-keeping — the AI executes within a narrow lane, but your hands are on the wheel. Level 3 is where it gets uncomfortable: the AI drives, but you need to take over when it signals. And Level 4 is the thing nobody has shipped yet.

Most "agentic" systems right now are Level 2 pretending to be Level 4 in the marketing copy.

I like to frame it with a question: if this agent transferred $10,000 to the wrong account right now, who gets fired? If the answer is "nobody, because it can't do that," you've got guardrails. If the answer involves HR, you've got a problem.

Where agents actually break

I ran the same task across three frameworks — give an agent a codebase, ask it to fix a bug, open a PR. Here's what happened:

The first agent got stuck in a loop. It kept reading the same file, suggesting the same fix, failing the test, then reading the file again. Like a Roomba bouncing off the same chair leg for 45 minutes.

The second agent fixed the bug but also — unprompted — refactored three unrelated files. Clean code, but wrong. Nobody asked for that.

The third agent worked. It found the bug, patched it, ran the tests, opened the PR. The difference wasn't the model. All three used the same one. The difference was the constraint system: the third agent had a hard limit on tool calls per task and a deny-by-default sandbox.

This isn't a model problem. It's an architecture problem.

The three controls that matter

If you're building or evaluating agent systems, I'd look at these three things before anything else:

Tool access is not permission. Just because an agent can call a shell command doesn't mean it should. A tight allowlist — specific binaries, specific flags — beats a fuzzy blocklist every time. Blocklists are for known threats. Agents generate novel ones.

Step limits are a safety feature, not a limitation. An agent that loops 200 times isn't "being thorough." It's lost. Cap the steps per task. If it can't do the job in 20 iterations, the task is either too big or the agent is stuck. Either way, looping more won't help.

Human-in-the-loop isn't optional for writes. Reads? Fine. Searches? Fine. But the moment the agent wants to push code, send an email, or modify a database — that should require a human to click "yes." Not a policy document saying it's required. An actual button.

I've seen teams skip this because it "slows things down." It does. That's the point. Speed without verification in an autonomous system is just faster failure.

The game analogy

I think about agent design the same way I think about NPC behavior in open-world games. You don't give every NPC the ability to modify the world. You give them a behavior tree — a fixed set of things they can do, conditions for when they do them, and hard boundaries they can't cross no matter what.

The shopkeeper NPC doesn't suddenly decide to join the main quest. The guard NPC doesn't open the gate because a player asked nicely in the chat box. Their autonomy is scoped.

AI agents need the same treatment. Scope autonomy to the task. Nothing more.

What I'm watching

Tool definition languages and agent-to-agent protocols are where the real action is right now. MCP (Model Context Protocol) is getting traction. A2A (Agent-to-Agent) from Google is interesting but early. The fight isn't about whose model is smarter — it's about whose agents can interoperate without blowing up.

But interoperability brings its own risks. Two constrained agents working together can sometimes do what neither could do alone. The combination needs its own set of constraints.

If you're building agents, start here: define what the agent is not allowed to do before you define what it can do. Deny-by-default. Your future self — and whoever signs off on the security review — will thank you.

How to Build a Modern On-Premise Data Lakehouse (Without Vendor Lock-in)

CyberMeshSec — Mon, 29 Jun 2026 01:20:06 +0000

Building a modern analytical platform usually rhymes with one thing: migrating to the cloud.

But what happens when operational realities, budget constraints, or strict compliance requirements demand a 100% on-premise solution?

Until recently, maintaining a local Data Lake meant choosing between two painful paths:

Wrestling with heavy, outdated Hadoop clusters.

Paying exorbitant licensing fees for proprietary software.

Today, the game has completely changed.

The open-source ecosystem has evolved to a point where you can build a robust, high-performance, and entirely decoupled Data Lakehouse running on bare metal servers.

No proprietary tech. No exorbitant fees. And absolutely no vendor lock-in.

In this article, I will break down the architecture, the technology stack, and the governance model we used to build a cutting-edge, in-house Data Lakehouse.

The Stack: Building an "Open-Source Databricks"
To ensure modularity and scalability, we applied the fundamental principle of modern data architecture: the separation of compute and storage.

Our stack was assembled using the absolute best the current open-source ecosystem has to offer:

Storage: MinIO
We replaced HDFS and AWS S3 with MinIO. It offers full compatibility with the S3 API but runs locally. Installed on NVMe drives with an XFS file system, it guarantees the incredibly high I/O throughput required for heavy analytical workloads.

Table Format: Apache Iceberg
Iceberg is the beating heart of our Lakehouse. It brings relational database features directly to the Data Lake, such as ACID transactions, painless schema evolution, and Time Travel (allowing us to query the exact state of the data at a specific point in the past).

Metadata Catalog: Project Nessie
Nessie acts as our Iceberg catalog. Its killer feature is providing a Git-like experience for data—allowing for branches, commits, and tags right at the data level.

SQL Engine: Trino
For the compute layer, we utilize Trino (formerly PrestoSQL). It is a lightning-fast, distributed query engine. Beyond querying our Lakehouse, Trino features query federation connectors. This allows us to join Lakehouse data directly with operational databases (SQL Server, MySQL) in a single query, avoiding unnecessary data duplication.

Ingestion & Transformation: dlt and dbt Core
To extract data from our sources, we use the Python library dlt (data load tool), which makes building resilient pipelines a breeze. For transformation and modeling, we rely on the industry-standard dbt Core, turning SQL code into a software engineering pipeline complete with version control, testing, and documentation.

Infrastructure: Bare Metal vs. Containers
To extract maximum performance exactly where it matters, we divided our infrastructure across two distinct servers:

The Core Server (Bare Metal):
This is where the heavy lifting happens. Services like MinIO, Nessie, and Trino run natively on Ubuntu Server 24.04, managed via systemd. We deliberately chose not to use Docker in this layer to avoid any virtualized network overhead or disk I/O bottlenecks. We ensure the SQL engine and storage communicate at the absolute maximum speed the hardware allows.
The Support Server (Docker):
On a secondary server, we run our entire support ecosystem containerized via Docker. This is home to tools like:

Dagster: Our data pipeline orchestrator.

Grafana & Prometheus: For monitoring server health metrics.

CloudBeaver: Our web interface for SQL exploration.

The Medallion Architecture and Decentralized Governance
The biggest challenge of a Data Lakehouse isn't technological; it's organizational.

To prevent our Lakehouse from turning into a "data swamp"—and to stop the IT team from becoming a bottleneck for report requests—we adopted the Medallion Architecture with strictly divided responsibilities:

Bronze Layer (Raw): Exact replicas of the source tables, with no business rules applied. Managed by IT using incremental polling via dlt.

Silver Layer (Cleaned): Also managed by IT. Here, data is cast to correct types, deduplicated, and standardized using dbt.

Gold Layer (Business): This is where the magic of decentralized governance happens. The modeling (Star Schema, aggregations, KPIs) is the exclusive responsibility of the QA and BI teams.

How does this workflow operate in practice?
When the BI area needs a new metric, they don't open a ticket begging Data Engineering for help. They develop the SQL model themselves in dbt, test it locally against Trino, and open a Pull Request in Git.

IT simply reviews the SQL code quality, approves the PR, and triggers the deploy. From that moment on, Dagster takes over and automatically orchestrates the schedule for that new table.

The Future: Evolving from Batches to Real-Time (CDC)
Currently, our architecture operates on V1, based on scheduled incremental polling. This delivers a latency that is perfectly acceptable for our current business needs.

However, our architectural roadmap is already prepped for V2. We will replace scheduled extractions with CDC (Change Data Capture) using Debezium and Kafka to read transaction logs directly from our operational databases. Data will land in Iceberg in a matter of seconds.

The beauty of this modern stack is that by swapping the ingestion engine at the Bronze layer, all our dbt models in the Silver and Gold layers will continue to function seamlessly, without us having to rewrite a single line of transformation code.

What’s Next?
Building this data infrastructure solved our analytical scalability issues, but it also opened the doors to new initiatives—especially the intensive use of Artificial Intelligence to generate internal applications and mini-systems integrated with this data.

With systems being rapidly generated by AI, a new (and critical) challenge emerged: How do we guarantee that an AI-generated portal accesses the Lakehouse securely?

In future posts, I will dive deep into how we solved this exact problem, covering Security, IAM (Identity and Access Management), API Gateways, and Row-Level Security in Trino.

🔔 Follow me here to stay updated on future articles! Drop a comment below: what are your thoughts on this architecture, and how do you handle the On-Premise vs. Cloud dilemma in your own projects?

The Asymmetric Fallacy: Why the Claude Fable Ban Hurts Cloud Defenders

CyberMeshSec — Mon, 22 Jun 2026 01:36:41 +0000

In June 2026, the U.S. Department of Commerce handed the cloud security community a massive geopolitical reality check. By forcing the global rollback of Anthropic’s Claude Fable 5 and Mythos 5 over autonomous "Zero-Day discovery" concerns, regulators attempted to put the genie back in the rack.

It won't work. In fact, from a SecOps perspective, it just tilted the board toward the attackers.

Here is the pragmatic breakdown of why this ban misreads the physics of modern cloud warfare, and what you need to do to fix your automated pipelines today.

1. The Asymmetric Fallacy

The regulatory logic relies on a flawed 1990s mental model: If we ban the sale of the lockpick, the doors stay safe. In 2026, the lockpicks are already open-source. When Washington takes an advanced reasoning engine away from a Cloud Security architect attempting to parse 10,000 lines of dirty AWS WAF JSON logs to build a dynamic remediation rule, the attacker doesn't pause.

The state-sponsored APTs in Shenzhen or St. Petersburg aren't using a rate-limited, KYC-verified Anthropic API. They are running heavily fine-tuned, localized weights of open models on private compute clusters.

The net result of the blockade:

The bad guys keep their autonomous offensive cognitive layer.
The good guys get downgraded back to writing Regex fallbacks in Python.

2. A New Failure Mode: "Regulatory Blast Radius"

For Cloud Engineers, this incident introduces a terrifying variable into our Threat Models. We are used to calculating the Blast Radius of an IAM misconfiguration or a compromised S3 bucket. We are not used to calculating the Blast Radius of a Subpoena.

If your automated SecOps pipeline looks like this:


text
[AWS CloudWatch Alarm] ──> [AWS Lambda (Python)] ──> [Claude Fable API] ──> [Auto-Ban IP]

You no longer have an infrastructure problem; you have a single point of geopolitical failure. If an export control drops at 3:00 AM on a Sunday, your automated WAF log triage goes blind instantly, throwing 503 Service Unavailable while a real attack hits your VPC.

3. The Zero-Trust LLM Architecture (The Fix)
Treating an LLM as an infallible external oracle is bad software engineering. Treating it as a permanent utility is bad risk management.

If you are building SecOps automation in AWS, your architecture must immediately adopt Cognitive Fallbacks.

The Architectural standard moving forward:
Abstract the Gateway: Never call anthropic.Claude(...) or openai.GPT(...) directly in your remediation logic. Route everything through an internal LLM Gateway (like LiteLLM or a custom abstraction class).

Declare the Fallback Chain: Your gateway must follow a strict degradation hierarchy:

Tier 1 (Primary - High Reasoning): claude-3-5-sonnet (or whatever survives the ban).

Tier 2 (Secondary - Hosted Fallback): gemini-1.5-pro (different jurisdiction/datacenter).

Tier 3 (The Iron Fallback - Local): A localized Mistral-7B-Instruct or Llama-3-8B running inside your own VPC on an AWS EC2 g5.xlarge instance.

If Washington kills Tier 1, the script degrades to Tier 2. If the undersea cables get severed, Tier 3 runs inside your private subnet and keeps the WAF rules updating. It will be slightly dumber, but it will be alive.

The Takeaway
You cannot build an immutable data fortress on top of a rented, politically volatile API.

The Claude Fable takedown isn't the end of AI-driven SecOps; it's the end of lazy AI-driven SecOps. It’s time to start treating AI weights like we treat Linux kernels: if you don't control the host, you don't own the compute.

How is your team handling the sudden API deprecation? Are you rebuilding your automation logic, or just shifting to another provider? Drop your strategy below.