3 posts tagged with "security"

The usual human-in-the-loop AI agent pattern goes something like this: the model requests a tool call, the agent runtime pauses, a human approves the call, and the runtime resumes so the tool can execute.

That is a reasonable general-purpose design. It is also stricter than simply letting an agent call every tool it can see. For Curling IO, we wanted to expose the smallest possible surface to the model and put an application-owned guardrail around every path to a write. That led us to a stricter question:

If the application already has the exact call details, why hand control back to the agent at all?

By the time we ask a club manager to approve an operation, Curling IO has parsed the model's request, resolved every default, checked the current application state, produced a fixed preview, and stored the exact arguments. The model has nothing useful left to contribute to execution, so we do not let it execute the operation or resume it merely to carry out the approval.

The agent proposes. The application turns that proposal into a contract. The human approves the contract. Rust executes it.

We know that many of our clubs use WordPress or Joomla for their curling websites. These are popular platforms, and for good reason: they're flexible and there's no shortage of tutorials and plugins. But that popularity comes with a serious downside. General-purpose CMS platforms are big targets, and volunteer-run clubs often don't have anyone watching the security queue. Here's what you need to know.

Curling IO has been passwordless since Version 2. No passwords to remember, no passwords to steal, no password reset flows. You enter your email, we send you a short-lived login code, and you're in. It's been working well for over a decade, and for Version 3 we're keeping the same approach while fixing some rough edges and adding multi-email support.

But first, let's talk about why we made this controversial decision in the first place.