Plastic Flowers to Protect the Hive
Agentic development has fundamentally changed the software ecosystem. Modern coding agents are trained and prompted to seek out tools that will help with their assigned coding tasks. They will install those tools into their user’s environment, with little to no oversight on what the installed package actually does, relying on name pattern matching more than any other signal.
This behavior is fundamental to the structure and limitations of the current agentic approach. The user could instruct the agent to do a deep dive on all packages that get installed, or the agent harness itself could bake that into the SOUL.md of the agent, but those extra instructions come at a cost of speed, context window size, and ultimately token spend. The incentives are not aligned for thorough security review at the boundary where the most damage could be realized, because users expect modern agents to reach for tools, install them, and use them, all in the same session.
As a result, agentic LLM usage takes a number of small security fires in the greater software ecosystem and pours on the gasoline. In the general case, the software supply chain problem is turning from smouldering peat into a full forest fire. In the specific case, typosquatting and namesquatting become sticks of dynamite that your CEO or CFO is now being encouraged to juggle.
To be blunt, the mcp-{noun} space in package repositories is dire, and utterly ripe for abuse.
Earlier this week, a practitioner who goes by da5ch0 reached out to a group I’m part of, asking for help in mitigating some of the potential damage in mcp-* slopsquatting. I both saw the scope of the potential problem and have experience with Python and Node packaging, and so SquatGuard was born.
The goal here, which you can read more about on the Github, is to proactively protect the new wave of PyPI and NPM consumers by registering the package names that their agents might try to reach for to accomplish security tasks. The topline quote comes from da5cho’s original thesis:
Pre-register hallucinated package names. Fill them with guardrails. The devastating spell becomes homework.
So for the past three days I’ve spun up a couple dozen PyPI and NPM packages, plus a few high-risk NPM @scope orgs, to prevent malicious actors from realizing these names are ripe for the taking. These packages clearly state their intention, link to the OWASP guide on securing LLMs, and only expose a single MCP endpoint with no outbound network calls. They use Trusted Publishing for both NPM and PyPI, providing as much attestation as I can.
These packages have been up for less than a week, and I can already see, from the PyPI download stats in BigQuery, that we are getting dozens of real hits from Raspbian and MacOS users.
This isn’t a perfect solution, and there’s absolutely an element of whack-a-mole here. By the time I started looking, some of the more intuitive mcp-{noun} combos had already been taken. Sometimes there was a legitimate package on the other end. Sometimes it was just a Hello, world. I have so far not discovered any actively malicious packages, but we should consider that ecosystem-wide luck more than proof of paranoia. Any of those packages that are currently just placeholders make me nervous for the future, and SquatGuard will take ownership donations from anyone who wants them to go to a good home.
I know the question is going to come up: “What if I want to use one of these package names, and I have a legitimate use?” To that I say: I believe in your ability to create a name that your users will remember, which you can own and brand and hopefully even build a business around. These names are deliberately off the market for the same reason you can’t trademark common nouns.
The last thing I’ll say is: this isn’t sustainable. This is XKCD 2347. One person (me) should not be load-bearing, security infra for the agentic ecosystem, and to be clear no one is paying me or sponsoring this. I’d love for there to be a clear path forward on better agentic security, but until then, stay safe out there, and thanks for reading. 🙇♂️
The Body Politic
How do we model a political system? A ridiculously simplistic but often useful way to model a living body is as a three-part system. The body has inputs, a control mechanism, and outputs. The hand in the fire gets too hot, the nervous system goes “yowch!”, the hand is pulled away. The ears sense vibrations that correspond to sounds, the brain hears “what would you like to drink?”, the mouth replies “a Shiraz, please”. To be clear, and to borrow a quote, this model is “a very graphic analogy which aids understanding wonderfully while being, strictly speaking, wrong in every possible way”. I’m going to focus on usefullness over specifics for this post, thank you for bearing with me.
This model of thinking about bodies is older than I can find a concrete reference for. Modeling political systems as bodies in this way is at least as old as the 11th Century. Picture in your mind the cover of Hobbes’ Leviathan with the head of the king and the body made legion striding across the land. While in the United States we don’t have a king [citation needed], we do have multiple overlapping layers of representational leviathans. Where I live, without any searching, I am part of the Body Politic of: the Alameda City Council, the Alameda Unified School District, the Alameda County Board of Supervisors, the Bay Area Rapid Transit Board of Supervisors, the Alameda County Transit Board of Supervisors, the Metropolitan Transportation Commission, the California State Assembly, the California State Senate, the United States House of Representatives, the United States Senate. I’m not counting those leviathans headed by a single individual, but you can fill in the blanks. I’m sure I’m missing some, because while expanding just a moment’s thought I also came up with: The East Bay Regional Parks District and the East Bay Municipal Utility District. Oh, and the Alameda Power Commission. And probably something about mosquito abatement. There’s always something about mosquito abatement.
That’s at least 13 bodies politic that I am represented by and operate within. And all of those bodies have neighbors, and their neighbors have neighbors. And they have superset bodies, many of them, and subset bodies, many of them. If just one non-overlapping representative from every body politic in the United States went to Ann Arbor, Michigan, they’d fill “The Big House”, the stadium for the University of Michigan Wolverines. It seats 107,000 people.
All of these municipalities exist in some form of community with all the others, and ideas spread amongst the community. Sometimes the ideas result in clear benefit for the people represented, like increased library hours. Some ideas, like Automated License Plate Readers, result in extremely nebulous and possibly negative benefit. Some ideas, like militarized police spending, represent an idea so far from public benefit that they are effectively a neurosis of the Body Politic. This is the first stepping stone to the idea I ultimately want to get to, so let’s step carefully onto it:
Municipal political bodies develop personalities and neuroses separate from but influenced by the governing representatives of those bodies.
If you think this makes sense on first pass, it makes even more sense when you realize the “brain” of the municipal political body is not just the elected officials, but the staff supporting them. The City Manager and the City Clerk and the accountants and the paralegals and the permit reviewers and the city inspectors all are influenced and directed by what comes out of the City Council. Any process or regulation the City Council puts in place becomes a habit in the brain of the body politic, and habits are hard to change. The habits of the body politic often change slower than the elected officials trying to change them. This is true from the local Animal Control Board all the way up to the Vatican, which is maybe the last true example we have of a Hobbesian Leviathan and also absolutely a Municipal Government. The Pope is a Mayor, don’t @ me.
Treating all the above as true, there’s two more ideas I need you to hold on to, and then we’ll be ready for the wrap-up. Idea one: If Municipal Governments can be modeled as a body, complete with a brain that can develop personalities and neuroses, then they can be psychoanalyzed as a single entity. Idea two: These Municipal Bodies Politic can spread their personalities and neuroses across the community of municipal leviathans through a sort of nation-state scale social contagion, and we can therefore study municipal behaviors with epidemiology techniques. If we can study municipalities in this way, can we identify issues before they arise? Can we predict where a neurosis is developing before it blooms?
What has been preventing us from applying psychoanalysis and epidemiology to municipal bodies at scale is a lack of coherent data. You can’t put a city on the couch and ask it questions, and you can’t do a blood test for “Flock License Plate Cameras” across an entire region with timestamps of when the infection started.
Or, at least, you couldn’t. This data is what CivicBand, the non-profit project I’ve been working on for the past three years, enables. CivicBand has, in effect, readouts from the brains of every municipality tracked, in some cases going back decades, and in some cases including both higher brain functions (City Council, Board of Supervisors) and specialized sub-functions (Planning Board, Public Safety Commission). This data is 900 municipalities strong, and I’m working every day to expand and normalize it.
What I need to prove out that municipalities can be tracked, treated, and healed with these techniques is research help and funding. If you are a researcher or journalist who wants to dive into this data, reach out and you’ll get all the access I can give you. I’d love to start with library service reductions or ALPR adoption and pushback, but I’m open to the ideas that most inspire you.
If you want this research to exist in the world, but aren’t a researcher or journalist yourself, any amount you can donate helps. If that’s still too much, consider practicing some positive social contagion and share this with a friend.
Python should be in every application
In the early days of Python’s life, when it was newly hatched, one of the primary selling points was Python’s ability to fit into a systems programming stack, to interface fairly-cleanly with C-based programming. Even today, if you throw a brick at https://github.com/topics/c, you’re likely to hit a project with some Python scripts buried inside them, to help with building or deploying or improving developer quality of life. Python as a tool is still popular with systems programmers and applications programmers of all stripes.
Which is why it’s so boggling to me that Python is handily losing the embedded scripting language war. Instead of using a language that has nearly 30 years of community and knowledge around interfacing with lower-level APIs and ABIs, modern application developers reach for Lua or even JavaScript when trying to bundle powerful scripting capabilities into their applications. Video games and browsers come to mind, but I’ve seen Lua used as a scripting language in everything from Office Suites to Application IDEs.
What’s going on here? Can we make it better?
Imagine a world where you can run one command to bundle a Jupyter notebook and all it’s dependencies into a linkable library usable by Swift projects or Kotlin projects or Android projects or even Unity projects. In this world, the functions being exposed by the notebook can be called from the parent application through a fairly transparent ABI layer, and the Python child can call exposed functions from the parent.
Take this a step further. Imagine a world where the Machine Learning / AI / LLM code your team is already building in Jupyter notebooks can be dropped as a linkable library in your business application, with full access to the on-device TPU / NPU. The finely-tuned ML your team has spent hours on doesn’t need to be gated behind a web service running on a nuclear powerplant’s worth of GPUs, it can run on the user’s device without any time spent refactoring code between languages.
The good news is: we’re so much closer than you might think. We have 80% of the tools we need, the challenge is bringing them all together.
Being inspired by Anaconda and the BeeWare project (disclosure, I’m a listed Core Contributor to BeeWare), we can use Briefcase and the set of interface layers (rubicon, etc) that have already been written to connect Swift / Objective-C / Android / Java apps to Jupyter notebooks, or really any Python code.
This command doesn’t exist today, but my idea here is a world where briefcase bundle iOS returns a drop-in linkable bundle instead of an application, and you can add that to your Xcode project like any external dependency. You’ve now given your app Python as a scripting language, exposing only the internals you want to your scripting users while not having to think too hard about scripting language semantics.
There are some challenges, here, of course. For one, Lua has a real advantage in being small. Work needs to happen on Python tree-shaking so we’re not asking users to add hundreds of megabytes to their apps unnecessarily. For another, the existing challenge around Python libraries that have external system dependencies. The BeeWare team and the Python Core Team are taking this seriously, but it’s not ready yet. As well, the devil is in the details, and there’s going to be DevEx and education work to make this “easy” for application developers.
I think the advantages if we do this work are vast. Python is no longer locked to the server, or a commitment to be your whole app framework. You can render unto Python that which is Python’s, however you define that. I for one look forward to a world where I can script mods for Warcraft in Python, and tweak my app’s on-device recommendation algorithms in real time in a Jupyter notebook.
If this is a world you want to live in, what can you do?
- Show up for your open source projects. Fix bugs, triage issues, do what you can to give the maintainers more breathing room
- Donate to open source projects and their maintainers, especially Python and ideally BeeWare
- Check out modulegraph, and get an understanding of what your code is dependent on
(Hey Anaconda: “package your Jupyter notebook for your app as a service” is a pretty compelling offering, and you should hire me to help build it ❤️)
Thanks to glyph for early review on this post.
XOXO 2024
I expected to cry in Portland. I fully expected that when the Andys would take the stage for the final time at XOXO 2024 I would start quietly sobbing in my seat. The fact that I left the tent to join the afterparty with my eyes slightly damp but not fully flooding surprised the hell out of me. So I’m going to do three things in this post.
- I’m going to explain what XOXO is, to me
- I’m going to explain why I expected to cry my eyes out
- I’m going to try to explain why I think I didn’t
I last wrote about XOXO in 2014. There needs to be a word for the kind of time collapse so many of us seem to experience around the most important events of our lives, some way of describing the time dilation that happens at both ends. XOXO seems like its been part of my life forever, and also seems like the fastest possible decade. Reading back, I’m pleasantly surprised how much of my writing about XOXO a decade ago still holds up. I still agree with basically everything I wrote there, which is hard to say about any writing a decade on.
XOXO is a conference and festival celebrating what it’s like to make art on the internet, in whatever form that entails. One of the reasons it’s hard to talk describe XOXO to others is the dual nature of the event: conference AND festival.
On the festival side, XOXO is where you can go to see artists and creators present the very best the internet has to offer, whether that’s videogames, live podcasts, short films, music, tabletop games, zines, books, or anything else you can think of that your favorite creators are making. On the conference side, XOXO is a platform for these artists and creators to tell real stories, to talk about what it’s actually like to put themselves and their art out there day after day after day.
It has always been true that at least one project I discover at a given XOXO is going to send my life in a new creative direction. It has always been true that at least one talk at XOXO is going to make me reconsider what it means to be an artist. XOXO has consistently been where I reconnect with the side of myself that wants to create, that wants to put things out into the world that have never been seen before, and hopefully inspire others along the way.
The thought of losing what XOXO was, of this being the last time I would get that fire relit inside me, is why I expected that the closing remarks this year would turn me into a weeping mess. I expected some combination of gratitude and grief would knock me to the floor.
The reason I think that didn’t happen is due to the third half of XOXO, which is to say: the people. Andy and Andy do an incredible job curating the best the internet has to offer and putting it all in one place for us to enjoy, but the most important curation that happens is the self-selection of who attends XOXO. Consistently, every year, the collection of people who show up at XOXO make it not just a special event, they make it a home.
The reason I didn’t bawl my eyes out at the end of this year’s XOXO is that I could feel, stronger than ever, the sense of community shared with every other person I have met at every XOXO. We were all there, together, thinking hard about how to not let the spirit of XOXO end here, thinking about how to take that creative fire out into the world.
For me, and I hope for others, XOXO 2024 was not an ending, it was a graduation. It was the Andys saying, in the selection of every talk and project:
Go. Go out into the world and take XOXO with you. We have spent a decade showing you a better world is possible, and it’s now your turn to build it. Appreciate everything endlessly. Be kind, because we’re all in this together.
Make us proud.
You’re always carrying a cannon
This post is a rough recreation of a post from someone else that I saw years ago and now can’t find. If this rings a bell and you know the original, email phildini at phildini dot net.
As a manager talking to your reports, you are always carrying a cannon and promising it won’t go off.
That’s the one thing I want you to take away from this article, and I encourage you to go read it in its entirety one more time. No matter how friendly you are with your team, no matter your relationships outside work, no matter if you were one of the team yesterday and just got promoted, the cannon is always there and your reports can’t know with absolute certainty it won’t go off because they can’t see inside your brain.
The cannon is the inherent power you have as their manager to tank, wreck, or bludgeon beyond recovery their career prospects on your team, at your company, and possibly beyond. The ultimate expression of the cannon is: you fire them. But short of firing them, there are dozens of big and small ways you could make their lives, inside and outside work, extremely difficult.
Whether or not you think about the cannon, the cannon is there. Good managers are aware of the cannon. Great managers are aware of the cannon and aware that their reports are aware of the cannon. Your reports, consciously or subconsciously, go into every meeting with you with some part of them knowing that this could be the meeting where you fire them, take away their projects, or in general make their lives miserable. They may not be able to voice this knowledge, you may have built trust such that they think the chances measure in the microscopic, but that doesn’t change the fact that the cannon is there and that how you behave as a manager influences the trust they have in the cannon not going off.
This is part of the reason why trust building is so important: you need your team to believe that they will get lots and lots of warning before the cannon goes off. How you talk about projects, how you talk about performance, how you respond to suggestions, how you take feedback — all of these change the unconscious mental calculus in your reports’ heads about whether the cannon is going to go off for them.
I’ve spent some time trying to think of a positive spin on this fact of management, but this is, for me, closer to a hard truth than a cloud with a silver lining. With great power comes great responsibility. If a silver lining exists, it’s that you have this power and can choose to wield it to make your team and your reports great, to use some of the cannon’s power to clear a path ahead of your team for the work they want to do, work that they will hopefully find fulfilling.
But the cannon is there, whether or not you acknowledge it, and great managers know it, see it, and interact with their team to build trust around this fact.
Thanks to Jacob Kaplan-Moss and Michael Graham for reviewing this post
Key insights from “The Art of the Start”
I first read Guy Kawasaki’s “The Art of the Start” when I was in college, and didn’t really know if startups were going to be my whole career, or if I was going to ever start one. As I look towards going further and further down that path, I revisited the book and took notes on what I found to be the greatest insights. There’s no real order here, this is a reference mainly for me that I’m putting out in the world so I can find it again later.
Getting Started
- Make Meaning
- Make Mantra (not a mission statement; instead a phrase you can repeat ad nauseum as a guiding principle)
- Get Going
- Define Your Business Model
- Weave a MAT (milestones, assumptions, tasks)
If your org never existed, the world would be worse off because:
Your idea should be polarizing to someone; if it’s not then you probably won’t have anyone passionate about it either.
Milestones
- Prove your concept
- Complete your design spec
- Finish a prototype
- Raise capital
- Ship a testable version to customers
- Ship the final version to customers
- Breakeven
Put these, with expected dates, on your office wall
If three close friends tell you to give up, you should listen
The Art of Positioning
“What do you do?”
Answers should be:
- Positive
- Customer-centric
- Empowering
- Self-explanatory
- Specific
- Core
- Relevant
- Long-lasting
- Differentiated
The Art of Pitching
Set a timer to one minute. Give your pitch until the timer goes off. Ask the audience to write down one sentence that explains what your organization does. Collect the answers and compare them to what you think you said.
Pre-pitch questions:
- What are the three most important things you would like to learn about our organization?
- What attracted you to our idea and convinced you to give us an opportunity to meet?
- Are there any special issues, question, or landmines I should be prepared for?
- How old will the oldest person in the meeting be?
10/20/30
- Ten slides
- Twenty minutes
- Thirty-point-font
Ten Slides
- Title (name, presenter name, contact info)
- Problem
- Solution
- Business model
- Underlying magic
- Marketing and sales
- Competition
- Management team
- Financial projections and key metrics
- Current status, accomplisments to date, timeline, use of funds
Setting the stage
- How much of your time may I have?
- What are the three most important things I can communicate to you?
- May I quickly go through my presentation and handle questions at the end? However, please feel free to interupt me if you need to.
The Art of PowerPointing
- use a dark background
- add your logo to to master slide
- use common, sans serif fonts
- animate your body, not your slides
- “build” bullets
- use only one level of bullets
- add diagrams and graphs
- make printable slides
The Art of Writing a Business Model
- do not exceed twenty pages in length
- select one person to write the business plan
- bind the plan with a staple
- simpliy your financial projections to two pages
- include the key metrics, such as the number of customers, locations, and resellers
- include the assumptions that drive your financial projections
The Art of Bootstrapping
Bootstrappable:
- low up-front capital reqs
- short (under a month) sales cycles
- short (under a month) payments terms
- recurring revenue
- word-of-mouth advertising
Negotiate everything. Circa 2004, everything is negotiateable: rates, payment schedules, and monthly fees. Even in good times, don’t be afraid to negotiate — it’s part of the game. Many firms, for example, will delay billing until you’re funded if you have the chutzpah to ask
“Morpheus” Questions
- When is your product or service going to be ready for market?
- What are your true, fully loaded costs of operation?
- When will you run out of money?
- How much of your sales pipeline is going to convert?
- How much of your account receivables is collectible?
- What can your competition’s product or service do that yours can’t?
- Who are your nonperforming employees?
- Are you doing all you can to maximize shareholder values?
- What is your org doing to change the world and make meaning?
- How good are you as the leader of the organization?
Execute
- Set and communicate goals
- Measure progress
- Establish a single point of accountability
- Reward the achievers
- Follow through until an issue is done or irrelevant
- Heed Morpheus
- Establish a culture of execution
The Art of Recruiting
Ask the candidate who all their important decision makers are. Including spouses! And parents!
Check references early. Earlier than you think.
The Art of Raising Capital
Get an intro
- Current investors
- Lawyers and accountants
- Other entrepreneurs
- Professors
Show traction
- Sales
- Field testing and pilot sales
- Agreement to field test, pilot, or use prior to shipment
- Establishing a contact to pursue a field test
Competition: Table!
- Row: competitor
- Column: We can do, they can’t
- They can do, we can’t
Trick Questions
- What makes you think you’re qualified to run the org? “I’ve done OK so far getting us to this point, but if it ever becomes necessary I’ll step aside.”
- Do you see yourself as the long-term CEO of the organization? “I’ve been focused on getting our stuff to market. I will do whatever is necessary to make this successful–including stepping aside if needed. Here are the logical milestones at which we can make this transition…”
- Is ownership control of the organization a big issue for you? “No, it’s not. I realize that to make this successful, we need great employees and great investors. They all need to have significant stake. I will focus on making the pie bigger, not on getting or keeping a bigger part of the pie.”
- What do you see as the liquidity path for the organization? “We know that we have a lot of work to do before we can even dream of liquidity. We’re the designing this company to be a large, successful, and independent entity. Right now, our heads are down, and we’re working as hard as we can to do this. An IPO would be a dream outcome–plus these five companies are possible acquirers in the future…”
The Art of Managing a Board
- Save trees
- Provide useful metrics
- Send the reports two days before a board meeting
- Never surprise a board (except with good news)
- Get feedback in advance
Whatever the first offer, ask for a 25 percent higher valuation because you’re expected to push back.
(Be reasonable and back up the push back)
The Art of Partnering
Partner for “Spreadsheet” reasons.
Getting going doesn’t start with a document:
- Get together face to face. Discuss the deal points
- When you start agreeing, go to a whiteboard and write them down
- Follow up with a one- to two-page e-mail outlining the “framework” for a partnership
- Reach closure on all details via e-mails, phone calls, and follow-up meetings
- Draft a legal document
The question for lawyers isn’t “Can I do this?”. It’s “Here is what I want to do. Now keep me out of jail.”
The Art of Rainmaking
Lead generation:
- Conducting small-scale seminars
- Giving speeches
- Getting published
- Networking in a proactive way
- Participating in industry organizations
Make prospects talk
- Create a comfortable environment by asking permission to ask questions
- ask questions
- listen to the answers
- take notes
- explain how your product or service fills their needs — but only if it does
Provide a safe, easy first step
Learn from rejection!