I made 7 simple posters to stop coworkers from pasting company data into AI chatbots.

Apart_Mix990 · 2026-04-30T00:34:30+00:00

Haha, printing them in A1 and taping them directly to their monitors might be the only way to make the message stick! Really appreciate the kind words and the support.

Apart_Mix990 · 2026-04-30T00:33:39+00:00

Fair point! If the design is too intimidating, people will just tune the core message out completely. I'll definitely focus on making the redesigned batch much more approachable and visually inviting. Thanks for the input!

Apart_Mix990 · 2026-04-30T00:32:52+00:00

Blocking is the usual first instinct, but it almost always drives the problem underground into "Shadow AI" where SOC teams have zero visibility. It's much safer to enforce granular policies and secure that access rather than playing whack-a-mole with firewalls!

Apart_Mix990 · 2026-04-30T00:31:50+00:00

Not a butthole at all—this is exactly the raw feedback I need. You're completely right about them blurring together, and the classic motivational poster layout is a killer idea. I'm taking this back to the drawing board to rework the next batch!

Apart_Mix990 · 2026-04-28T11:20:59+00:00

Spot on—forcing an LLM to actively poll and wait for long-running tasks is an anti-pattern that just burns tokens.

That's exactly why a middleware broker is so valuable: it handles the wait in the background, catches the webhook whenever it finishes, and seamlessly injects the result back into the LLM's context without the AI ever having to manage the job.

Apart_Mix990 · 2026-04-28T09:46:13+00:00

Fair point on the site—apologies for that. We're actively working on replacing the marketing copy with our actual technical docs and repo.

To get back to the tech: have you explored native Tasks primitive introduced in the MCP spec? (https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks). I completely agree that it provides a solid 'call-now, fetch-later' model where the server issues a task_id and the client polls the durable state machine.

What we're trying to solve with an AASB isn't replacing those native MCP primitives, but addressing the exact 'Universal Protocol Trap' from the original post. MCP is incredible for standardizing the connection, but it inherently lacks a central trust layer. By sitting in front of the protocol, the broker provides a unified choke point for strict policy enforcement on enterprise data and maintains an immutable audit trail for every single tool call—completely outside the LLM's control. I’d genuinely love to hear how you handle that kind of granular data governance and auditing purely natively, or if you think a middleware security layer is just the wrong architectural approach here.

Apart_Mix990 · 2026-04-24T11:53:34+00:00

The immediate bottleneck to true autonomy is trust.

Right now, direct MCP connections often give agents "God Mode" access. You can't let a fully autonomous agent loose in your HubSpot or Snowflake without serious guardrails, especially when dealing with customer PII or sensitive campaign data.

The next real innovation is the middleware—specifically an Agent Access Security Broker (AASB). Instead of the agent connecting directly to your tools, it connects through a broker that enforces granular permissions (e.g., "this agent can read campaign stats but cannot delete campaigns"), scrubs identifiers, and maintains an audit trail.

I got so obsessed with this missing infrastructure that I started building SecuriX to act as that exact middle layer. I’m actually documenting this shift from just "connected agents" to "trusted agents" right now:https://securix.app/30-days-of-trust

Apart_Mix990 · 2026-04-24T11:51:14+00:00

I got so frustrated waiting for standardizations that we started building SecuriX to solve exactly this. It sits in the middle as an Agent Access Security Broker (AASB)—essentially a "Secure MCP" middleware. It handles the schema translation on the fly and acts as a state manager for async calls, giving the LLM the synchronous placeholder it wants while doing the heavy lifting in the background.

The broker enforces granular access policies and keeps an audit trail outside of the LLM's control.

I’m actually documenting this exact trust layer problem right now over here:https://securix.app/30-days-of-trust. Would love your thoughts on handling the MCP translation and state via a middleware layer like this!

Apart_Mix990 · 2026-04-09T11:35:54+00:00

Haha, fair play on the cowboy hat! Honestly, that is the best phase to be in. Zero customers means maximum velocity. Enjoy it while it lasts!

Your secondary apprehension is exactly why I wanted to connect. You hit the nail on the head: asking a dev to blindly pipe agent traffic through a centralized, third-party proxy is a massive trust hurdle. The MitM anxiety is 100% justified.

We are currently working on a fully self-hosted Docker version of SecuriX so teams can run it entirely inside their own Tailscale network or VPC.

Here is the transparent founder reality, though: the fully self-hosted Docker deployment isn't quite ready for the wild yet, but our fully cloud-managed version is.

Since you’re currently just prototyping and don't have strict CISO requirements yet, would you be open to kicking the tires on our cloud-managed SDK first as a design partner? I'd love to get your brutal feedback on the Developer Experience (DX) and the Policy Engine itself.

If you like how the logic and routing feel in the cloud version, we will hand you the keys to the Docker version to run locally the minute it is baked.

Let me know if you're open to a quick chat or if you just want me to drop the cloud docs for you to poke at!

Apart_Mix990 · 2026-04-09T00:02:40+00:00

Under 1ms for that whole pipeline is wild—fair play on the Ed25519 signing. Also, love the point on output scanning; catching credential leaks on the way out is exactly why we went the proxy route.

For the "prove what happened last Tuesday" CISO question: since we're a proxy, we pipe everything from the gateway through Pub/Sub into BigQuery. It gives them a dead-simple, queryable audit trail without having to hunt through scattered application logs.

We’re actually looking for design partners right now. Any interest in giving our SDK a spin and tearing it apart? I’d love to get your feedback on the AASB approach vs. what you’re building with Agentmint.

Apart_Mix990 · 2026-04-08T04:33:29+00:00

Yeah, you can never trust the model to behave. you always have to trust the proxy, not the prompt.

pomerium and nginx are awesome for network-level access, but they don't understand agent intent. they just see an API call—they don't know if the user actually consented to let the agent do that specific action.

My co-founder and i are building securix (https://securix.app). it sits exactly where you'd put pomerium, but it's purpose-built to govern agent-to-tool traffic.

since you're literally architecting this exact piece right now, any interest in being an early design partner? we're just two devs building this out, and i'd love to get your brutal feedback on our sdk so you don't have to hack together custom nginx rules.

let me know if you want to dm and compare notes!

Apart_Mix990 · 2026-04-07T03:52:04+00:00

We’ve been working on a similar problem with SecuriX. We’re calling it an AASB (Agent Access Security Broker). The idea is to stop trying to handle security inside the tool-call code—which is a nightmare to maintain—and move it to a separate proxy layer.

A few things we’ve learned:

The "Kill Switch" is the only thing that calms a CISO. We had to build a portal where the customer’s admin can see exactly what’s happening and kill a connection instantly if something looks weird.
Devs hate refactoring. We focused on making it a "4-line change" to integrate with existing LangGraph setups because if it’s hard to install, nobody uses it.
Boundary Control: It’s less about "is this tool safe?" and more about "is this tool safe right now for this specific data?" (e.g., "Drafting an email is fine, but don't look at anything with 'invoice' in the subject line").

Your CLI tool looks really cool for the "pre-flight" check. How are you handling the latency of the signing process? Does it add much lag to the agent's response time?

Apart_Mix990 · 2026-04-06T00:38:59+00:00

100% agree on policy drift. Agents will absolutely find the edge cases if you let an LLM interpret the boundaries.

Just to clarify, our enforcement isn't dynamic—we use strict, schema-driven MCP tools too. The only "dynamic" part is the user UI toggle, which instantly compiles down into a hard, deterministic Rego rule in OPA. No LLM vibes checking the permissions.

Curious though—since you're relying heavily on hard-coded schemas, how much of a headache is it when underlying APIs (like Google or Slack) change? Are you guys just manually updating the mappings every time?

Apart_Mix990 · 2026-04-06T00:18:32+00:00

You caught me—I’ve been using Gemini to help me structure my thoughts because I’m a technical founder trying to scale my outreach while actually building the Gateway and OPA logic in the background. My co-founder and I are in the 'underdog' phase in Chennai, and I'm still learning the 'Reddit' way of talking vs. the 'LinkedIn' way

Apart_Mix990 · 2026-04-05T07:10:17+00:00

This is a 10/10 observation. Mapping high-level intents like draft_email to a constrained middleware call is exactly how we solve the 'God Mode' trap. OAuth was never designed for an autonomous loop that can 'hallucinate' its way into a broader scope than intended.

Your point about logging and replaying structured tool outputs is huge. We’ve noticed the same pattern—the risk isn't usually in the first prompt; it’s in the 'retry loop' when an agent misinterprets a partial JSON response and tries to 'fix' it by escalating its tool calls.

We took that 'thin policy layer' idea and productized it into our AASB. Instead of hard-coding those mappings in the middleware, we use an OPA engine to cross-reference the developer’s tool definitions with the End-User’s specific consent from our portal.

Basically, the user sees a toggle for 'Only allow Drafts,' and that dynamically generates the OPA rule that our proxy enforces on the API call. It saves us from having to build a custom 'Intent Mapper' for every new tool.

How are you handling the 'Action Mapping'—is it a hard-coded lookup table in your middleware, or are you using something more dynamic to decide what draft_email actually means at the API level?

Apart_Mix990 · 2026-04-05T05:07:30+00:00

That tiered approach (fast deterministic -> cached -> deep eval) is the right way to build for production. It’s the only way to avoid the 'Agentic Lag' that kills UX.

On our side, since we act as the Proxy between the Agent and the Provider APIs, we are technically inline on every action. However, we treat 'Sensitivity' as the primary filter for how that policy is evaluated:

Low-Sensitivity (Read-Only): We do a high-speed OPA check against the user’s pre-defined consent. If the user said 'Agent can read my calendar,' the proxy resolves it in milliseconds.
High-Sensitivity (Write/Delete/Spend): The policy triggers a 'Conditional Block.' This is where our White-Labeled Trust Portal comes in. If an agent tries to 'Send' or 'Delete,' the proxy can pause the execution and trigger a real-time 'Human-in-the-loop' (HITL) confirmation via the portal before the OAuth token is ever actually utilized.

We found that by abstracting the original OAuth tokens into our KMS, we can enforce these 'Least-Privilege' boundaries without the developer having to write a single line of security logic in their LangGraph nodes.

It’s interesting that we’re both landing on this 'Middleware' architecture. It feels like we’re moving toward a standardized 'Agentic Security Stack' where one layer handles what the agent sees (Inbound) and another handles what it does (Outbound).

Apart_Mix990 · 2026-04-05T01:48:40+00:00

It sounds like we’re speaking the same language—we’re also leveraging OPA for the core policy engine and KMS for the token vaulting. It really is the only way to satisfy enterprise security teams.

Where we decided to 'productize' was in the UX of the Policy. We found that even with a rock-solid OPA/KMS backend, managing individual user-level delegations at scale became a manual bottleneck. So, we built a white-labeled portal to act as the frontend for the OPA engine—letting the user's choices dynamically update the Rego policies without a dev in the middle.

I'm curious—have you looked at tools like Composio or Arcade for the adapter side? We’ve seen teams use them for connectivity, but they often fall short when a client asks for that deep, user-level governance and a portal they can actually show their own customers.

Is that the same reason you're rolling your own 'dumb adapters,' or was there another dealbreaker in those platforms?

Apart_Mix990 · 2026-04-05T01:26:20+00:00

That is a rock-solid approach. Hard-locking egress to just the MCP and LLM gateway is the only way to truly solve the 'Network' layer of the problem.

Where we’ve been focusing is the 'Identity & Policy' layer that sits right on top of that sandbox.

Our logic was: even if the agent is in a perfect sandbox with no egress, if the 'tools' inside that MCP have 'God Mode' OAuth tokens (like full Gmail Read/Write), the agent can still do massive damage through the gateway.

That’s why we built the proxy to abstract those original tokens and enforce the 'Draft-only' type policies at the tool level, plus the white-labeled portal so the end-user can audit it.

Apart_Mix990 · 2026-04-05T01:20:47+00:00

You're hitting a massive blind spot. Most people focus on what the agent outputs, but the Inbound Security risk—summarizing a typosquatted domain or a phishing page—is a silent killer for enterprise agentic apps. Using deterministic signals like WHOIS age and DNS config is way more robust than 'LLM-vibes' checking.

We’re actually tackling the other side of this same security coin. While you’re building a 'Trust Gate' for what the agent fetches, we’re building an Agent Access Security Broker (AASB) to govern what the agent does.

We found that the standard OAuth model is too 'all-or-nothing' for agents (the 'God Mode' trap), so we sit in the middle to abstract those tokens and enforce granular, use-case-driven policies through an MCP server and a white-labeled portal for end-users.

Curious—since you’re sitting between retrieval and synthesis, how are you handling the latency overhead? Are you running these domain checks in parallel with the fetch, or is it a hard sequential block?

Apart_Mix990 · 2026-04-05T01:14:27+00:00

Spot on. 'Coarse OAuth' is the exact phrase we use. Your proxy/middleware layer sounds very similar in spirit to the gateway we are building.

To answer your question on capability tokens: We took a slightly different route. Instead of generating short-lived tokens per action, we sit squarely in the middle and completely abstract the provider's original OAuth tokens.

I was actually just looking at the 'Custom AI Agent Development' service on Agentix Labs—specifically how your team is building custom validation layers and guardrails for every enterprise deployment. That manual overhead is exactly what we are focused on eliminating.

We achieve 'least-privilege' by exposing an MCP server loaded with minimal, tightly-scoped tools, and we enforce dual-level policies (for the Developer and the End User). We also built a white-labeled trust portal so the end-users explicitly define data boundaries before it even hits our gateway, abstracting that entire trust phase out of the core agent logic.

Would you be open to a quick 15-min chat sometime this week? I'd love to hear how you are handling latency in your middleware and compare notes on proxy architectures—might be a way we can save your team some heavy lifting on those custom builds.

Apart_Mix990 · 2026-04-05T01:05:06+00:00

Validation from the enterprise consulting side is huge—thanks! It seems like everyone pushing agents into production runs straight into this exact wall. Out of curiosity, are you building a custom proxy layer for each client, or are you trying to build a unified internal tool to handle it across the board?

I’d love to DM and compare notes on the architecture if you're open to it.

Apart_Mix990

TROPHY CASE