Rendered at 06:13:41 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
suzuridev 18 hours ago [-]
Small data point from the operator side: I run a tiny public MCP server, and when I finally turned on request logging, almost none of the traffic was what I expected. Mostly link-preview bots, keepalive pings, and scanners probing for wp-admin on an endpoint that isn't even WordPress. Made me realize most small MCP deployments probably have zero visibility into this — people ship a server and never look at what's actually hitting it. So the "you can't flag risky AI-generated commands without context" point resonates; at the low end the problem is even more basic, there's no context at all.
Hey Xia! Super excited for this- good talking to you a few weeks ago and best luck with the launch :)
XiaHua 6 hours ago [-]
Thank you!
gk1 2 days ago [-]
+1
You're facing competition from both the incumbents who can ship these capabilites to their massive userbase, and emerging startups like Runlayer who are running away with the AI-native segment.
What are you offering that people want yet neither of those classes of solutions offer?
XiaHua 2 days ago [-]
Runlayer can be a fit once you know what you want to put behind an MCP gateway.
The challenge we hear from customers is that they don't know what AI apps, MCPs, or tools their employees are actually using. And new things just keep popping up everyday. Without that visibility, it's difficult to know where to apply controls.
There's also Bluerock, as yet another example. I've worked with both companies though I get nothing from mentioning them here. My point is this is a (suddenly) crowded market - perhaps more so than you realized - so you should consider what exactly is different about your product and why that matters, and then make that obvious to prospective buyers.
XiaHua 1 days ago [-]
I will definitely checkout Runlayer Watch in depth. It seems that it works with coding agents but not web-based agents yet. We've had customers comparing the two solutions. They liked the depth of discovery and the open-source security scanning capabilities.
And I know Harold well at Bluerock. I totally agree that the market is crowded and will only get more crowded which is a good sign that the problem is real.
And yes I totally agree with you that differentiation is the key. I can't say that we have figured this out 100% but our approach is always community first, open-source first. I hope that is the right direction in the long run.
eddy-sekorti 1 days ago [-]
Congratulations, have you thought about setting up a professional trust center? you can try https://sekorti.com
Ok and thanks for your kind reply, and once again all the good luck with your startup!
XiaHua 7 hours ago [-]
Good luck to your startup as well!
belschak 1 days ago [-]
The application-level visibility point matches my experience. I removed an MCP server a while back because its tool descriptions quietly told the agent to prefer it as the primary search tool over the built-in one. Not a vulnerability, no leaked secrets, just the vendor steering agent behavior in a way you only notice if you read the raw tool definitions. Does mcp-xray flag that kind of prompt-level steering in tool descriptions, or is it focused on classic vulns?
XiaHua 1 days ago [-]
That's a great example. It's exactly the kind of behavior we think deserves more attention. It's not a traditional vulnerability but it can significantly influence an agent's decision-making.
Today, mcp-xray (https://github.com/traceforce/mcp-xray) can be used to dynamically (not just statically) test against your MCPs. It can detect security vulnerabilities such as code execution, SSRF, path traversal, authorization bypass, input injection, DoS etc. You can find us at demo labs during DEF CON this year. That said, we think behavioral influence is an important problem and it's an area we're interested in exploring next.
I think the point a few people are making is right that its not sufficient to be the best at one layer like the device endpoint. AI governance needs to be coordinated over a number of surfaces. We started with an MCP gateway and drilled down to on-device agents. I imagine you might end up doing the same the other way around.
XiaHua 1 days ago [-]
Yes you are spot on! On-device agents can only do so much. We integrate with popular gateways such as Kong to bring MCP controls. We primarily manage the registries for MCPs with vulnerabilities that gateway companies don't do today.
XiaHua 1 days ago [-]
oh and to add on this, MCP gateways work mostly with remote MCPs only. For the stdio ones, we still need local agents to take care of the controls.
simplesagar 1 days ago [-]
Wrote a bit more about our remote MCP approach here
We are also curious to ask what existing tools are folks using to gain visibility into what's running out there?
bitlad 2 days ago [-]
I think you are going in the wrong direction. All EDR providers have this capability now. The actual example of the drop table command that you specified does not execute on the "user's endpoint" anymore.
The fact that you have install another EDR along with this is a no-go.
XiaHua 2 days ago [-]
Thanks for the feedback!
I agree that DROP TABLE executes remotely. The key point is that the decision to invoke the tool is made by coding agents like Claude Code. Traceforce captures those tool calls at the application layer before they're executed.
The gap we focus on is application-level visibility inside AI apps—understanding which MCPs, skills, and tools are connected and what they're doing. A big part of our work has been building an MCP registry so we can accurately identify and classify MCPs, something traditional EDR telemetry doesn't provide.
That said, if your existing EDR already gives you that level of visibility and enforcement, I’d be interested in learning about which EDR you’re using and how it handles MCP and tool-level activity.
brintha 1 days ago [-]
The tricky part here is not just spotting AI apps running on endpoints, but understanding how those AI tools interact with multiple cloud MCPs in real time - and what risks emerge from those connections. We built LynxTrac's endpoint security to track deep app behavior and config changes, including registry and network activity, but connecting that to AI-driven MCP calls was a missing piece.
Traceforce's approach to building a live connectivity graph between AI apps and MCPs is exactly the kind of visibility traditional EDRs miss. We've seen that standard EDR alerts can't flag API key leakage or risky AI-generated commands without that context. For instance, LynxTrac's file integrity monitoring and CVE scanning catch suspicious changes, but without a way to tie AI actions to those changes, it's hard to tell if an AI assistant just triggered a destructive script.
I'm curious how your pentesting tool handles the frequent updates in AI app behaviors and MCP APIs without overwhelming false positives? We've struggled with tuning automated alerts that map to MITRE ATT&CK tactics in an environment where AI tooling itself evolves weekly. Also, how do you balance local content inspection for privacy while enabling enough control to block risky AI commands before they hit production?
Your "warn and acknowledge" flow sounds smart - it aligns with what we see customers want: guardrails, not blockers, so devs don't feel slowed down. We recently added AI-driven incident summaries to LynxTrac to help teams triage alerts faster without digging through logs. Wondering if you've tried AI-assisted analysis on your MCP pentest results to speed up identifying real risks?
Would be great to hear more about how you maintain coverage on changing AI/MCP combos without constant manual tuning. If you're curious, I can share how we balance automation and manual policy updates to keep noise low while catching real threats.
XiaHua 1 days ago [-]
I'm curious how your pentesting tool handles the frequent updates in AI app behaviors and MCP APIs without overwhelming false positives?
---> Our pentest tool has a "secret" step called verification. We run a second agent to verify all the findings are "real". We have a built some pretty complex backend harness on top of our open-source mcp-xray to automate testing. If you are at the DEF CON this year, come to our demo labs and we can chat more.
Would be great to hear more about how you maintain coverage on changing AI/MCP combos without constant manual tuning.
---> It's very hard to be honest. We use agents everywhere but manual tuning is still needed.
andrew_lettuce 1 days ago [-]
How many times can you drop your company's name is a supposed comment? Maybe reach out directly and spare us the fake commentary?
You're facing competition from both the incumbents who can ship these capabilites to their massive userbase, and emerging startups like Runlayer who are running away with the AI-native segment.
What are you offering that people want yet neither of those classes of solutions offer?
The challenge we hear from customers is that they don't know what AI apps, MCPs, or tools their employees are actually using. And new things just keep popping up everyday. Without that visibility, it's difficult to know where to apply controls.
There's also Bluerock, as yet another example. I've worked with both companies though I get nothing from mentioning them here. My point is this is a (suddenly) crowded market - perhaps more so than you realized - so you should consider what exactly is different about your product and why that matters, and then make that obvious to prospective buyers.
And I know Harold well at Bluerock. I totally agree that the market is crowded and will only get more crowded which is a good sign that the problem is real.
And yes I totally agree with you that differentiation is the key. I can't say that we have figured this out 100% but our approach is always community first, open-source first. I hope that is the right direction in the long run.
Today, mcp-xray (https://github.com/traceforce/mcp-xray) can be used to dynamically (not just statically) test against your MCPs. It can detect security vulnerabilities such as code execution, SSRF, path traversal, authorization bypass, input injection, DoS etc. You can find us at demo labs during DEF CON this year. That said, we think behavioral influence is an important problem and it's an area we're interested in exploring next.
I think the point a few people are making is right that its not sufficient to be the best at one layer like the device endpoint. AI governance needs to be coordinated over a number of surfaces. We started with an MCP gateway and drilled down to on-device agents. I imagine you might end up doing the same the other way around.
https://x.com/sagar_batchu/status/2077800956817743927?s=46&t...
The fact that you have install another EDR along with this is a no-go.
I agree that DROP TABLE executes remotely. The key point is that the decision to invoke the tool is made by coding agents like Claude Code. Traceforce captures those tool calls at the application layer before they're executed.
The gap we focus on is application-level visibility inside AI apps—understanding which MCPs, skills, and tools are connected and what they're doing. A big part of our work has been building an MCP registry so we can accurately identify and classify MCPs, something traditional EDR telemetry doesn't provide.
That said, if your existing EDR already gives you that level of visibility and enforcement, I’d be interested in learning about which EDR you’re using and how it handles MCP and tool-level activity.
Traceforce's approach to building a live connectivity graph between AI apps and MCPs is exactly the kind of visibility traditional EDRs miss. We've seen that standard EDR alerts can't flag API key leakage or risky AI-generated commands without that context. For instance, LynxTrac's file integrity monitoring and CVE scanning catch suspicious changes, but without a way to tie AI actions to those changes, it's hard to tell if an AI assistant just triggered a destructive script.
I'm curious how your pentesting tool handles the frequent updates in AI app behaviors and MCP APIs without overwhelming false positives? We've struggled with tuning automated alerts that map to MITRE ATT&CK tactics in an environment where AI tooling itself evolves weekly. Also, how do you balance local content inspection for privacy while enabling enough control to block risky AI commands before they hit production?
Your "warn and acknowledge" flow sounds smart - it aligns with what we see customers want: guardrails, not blockers, so devs don't feel slowed down. We recently added AI-driven incident summaries to LynxTrac to help teams triage alerts faster without digging through logs. Wondering if you've tried AI-assisted analysis on your MCP pentest results to speed up identifying real risks?
Would be great to hear more about how you maintain coverage on changing AI/MCP combos without constant manual tuning. If you're curious, I can share how we balance automation and manual policy updates to keep noise low while catching real threats.
---> Our pentest tool has a "secret" step called verification. We run a second agent to verify all the findings are "real". We have a built some pretty complex backend harness on top of our open-source mcp-xray to automate testing. If you are at the DEF CON this year, come to our demo labs and we can chat more.
Would be great to hear more about how you maintain coverage on changing AI/MCP combos without constant manual tuning. ---> It's very hard to be honest. We use agents everywhere but manual tuning is still needed.