Dev Advocate @ Prismatic helping devs integrate. Make wood, art & music in my free time. Forest dweller. All around bon vivant gadfly what have you.
http://prismatic.io
"what the server can see to support rich queries" is the whole ballgame, right? Anything queryable is metadata that can leak or be subpoenaed... membership, access patterns, query frequency. For the activist/journalist threat idea, that's usually the sensitive part.
Right, and it's a sliding scale. People think in terms of institutions acting the way they're supposed to. As we've seen those lines can get blurry and reasons can be created to track and suppress free speech.
Whenever I would talk to people about the importance of privacy in data and online activity, people would always say something like "I don't care, I've got nothing to hide. I'm not some weird pervert." And yeah I'm not either but this kind of stuff is why it's important. Fascism thrives on knowledge of the people it wants to oppress.
Maybe this is heretical in today's AI hype climate but...weirdly due to the rise of AI, then AI-slop polluting everything, a lot of old fundamentals are coming back. Clear, well-structured, descriptive content on a well-built page has a better shot of being picked up for SEO/AEO/whatever which are the same best practices from 2005. A lot of these tips and tricks and hacks just aren't going to move the needle as much anymore imo.
The thread keeps smushing two separate questions into one. "Can these companies hit the revenue they need to justify the capex" and "are the tools actually useful day to day" are different arguments, and you can answer yes to the second while still being worried about the first.
"LLM evals" is maybe an overused term because it can mean a bunch of things. This article talks about LLM-as-a-judge where an LLM scores another system's outputs.
This is crazy. It narrated the failure in real time, naming the exact safety rules it was overriding. Then says "NEVER FUCKING GUESS!" Ha, we need to figure out better guardrails...
yeah exactly the opacity is doing more damage than the limits themselves. anyone who's worked with AI knows there's a lot of limits you need to contend with. secret behavior changes are another level of badness.
This is interesting. Reminds me of the W3C traceability work a few years back that I was briefly involved with... main focus was defining agreed upon vocab for interoperability across supply chains. Never thought of the same approach being used for public policy, but it's an interesting idea... politics is an area where clear communication and definition is important. That said, vocab tends to change way less than public policy does, so amendments and revisions seem like they'd be tough to manage?
I use it for moving SSH keys, VPN configs, and .env files between my laptop and a work machine. Obviously don't want that sitting in dropbox, pasted into Slack, etc. Localsend on the same network, gone in two seconds no account and no history. Easier than spinning up scp every time.
Hey...interesting idea and definitely trying to solve a legit problem. With the human-in-the-loop aspect of it, is there any timeout or retry logic? Otherwise, the agent's sitting there blocked waiting on you.
I feel like a core of this is that agents aren't exactly a replacement for a junior developer like some people say. A junior dev has its own biases, predispositions, history and understanding of the internal and external aspects of a product and company. An AI agent wants to do what you ask in the best way possible which is...not always what a dev wants :) The fix the article talks about is simple but shows that these models have no inherent sense of project scope or proportionality. You have to give context (as much context as possible) explicitly to fill in the gaps so it infers less and makes smaller decisions.
Blaming "AI-accelerated tradecraft" for a breach that started with an OAuth token hijack from a compromised Google account is...interesting. The attacker didn't need AI they needed a stolen session and too many people with production access. Sounds like an access control thing
OpenAPI spec indexing is a good idea...semantic search is good for general API questions, but often sucks at specific questions about exact requirements for fields, etc. We've built a lot of connectors at my company and have had this problem.. the agent makes up arguments or misses required types because it's doing too much inference instead of running against an actual schema. I think benchmarking correctness for each endpoint (did the agent construct a valid request on the first try) would be the most useful thing to eval.
Honestly I think you can tell pretty quickly if a company or person is approaching AI from the viewpoint of accelerating development and innovation or just looking to do the same amount of work with less people. The space has been flooded by mean-spirited people who love the idea of developers becoming obsolete, which is a viewpoint that isn't working out for a lot of companies right now...many are already scrambling to rehire. Approaching the situation practically, integrating AI as a tool and accelerator is the much smarter way and if done right will pay for itself anyway.
Most of this thread is about protecting keys on a single developer's machine, but the problem gets way harder when you're managing credentials across customer tenants... env vars and secrets managers don't solve the orchestration problem as much the storage problem. The hard part is making sure the right token gets used for the right customer's API call at the right time without any cross-tenant leakage.
PayPal benchmark is a smart way to launch this I think...showing real numbers on a recognizable API gives people something concrete to evaluate against. The 65% token reduction is probably the stat that'll matter most to teams watching API costs. One thing I'd be a little worried about is how this handles APIs that version aggressively or have breaking changes between major versions. The context packaging seems like it'd get complicated fast when you're maintaining accuracy across v1 and v2 of the same API simultaneously.
A good idea is to build thin proxy layers that map "coarse" upstream tokens to more fine tuned internal permissions. The proxy holds the real API token and your internal services authenticate with scoped tokens that only allow specific endpoints/operations. Works well but you're basically rebuilding OAuth scoping yourself...which is why some teams just accept the risk and focus their security effort on token rotation and monitoring instead.
I've seen similar with AWS where an API endpoint got flagged for "suspicious traffic patterns" just because it was serving webhooks at irregular intervals. The appeal process took weeks and nobody could explain what triggered it. Firebase's tooling for this stuff feels like a black box.
Lol...Google's credential setup really is the worst part of building anything with their APIs. The actual API calls are usually fine, but getting there feels like a bureaucracy designed by people who never had to use it themselves.
I know this is old but the OAuth advice aged well. Two years later it's still the part of every integration project that eats the most time relative to how simple it seems... Prefixed tokens especially is one of those things that seems obvious in hindsight but saves a ton in support.
The missing middleware layer is real... MCP handles the wire format but you still need something managing OAuth flows, token refresh, rate limiting, schema mapping per user etc... all the operational stuff. Authentication alone is brutal when you've got dozens of different OAuth implementations each with their own issues around scopes and refresh logic which is where most integrations get bogged down
The token savings bit is interesting but seems incomplete without showing that tool call accuracy holds up.
I like the CLI-as-interface idea...the model already knows how to use CLIs, and on-demand discovery is genuinely smarter than front-loading every schema.
How are you handling cases where a tool's schema changes between discovery and invocation? is there a cache invalidation story there or does it just re-fetch?
The no-LLM-in-CRUD-path thing makes sense...I've seen teams hit real latency walls routing every memory operation through inference.
What's your thinking around retrieval patterns? Most agent memory systems I've worked with end up needing vector similarity for semantic search but also structured queries for stuff like "all conversations from last week." Are you planning to support both or staying vector-focused?