Short answer
#Three proposals on one desk
I have watched this scene many times, and it hardly changes. A founder has three security proposals on the desk, and all three arrived in the same week.
The first came from a contractor: an annual subscription to a policy platform for AI agents. The deck has the word enterprise in it and a diagram of twelve boxes. The second came from a friend of an investor: a penetration test before the round, because that is what people do. The third came from the company's own technical lead: touch nothing until the round, there are four of us and a release is on fire.
Each of the three sounds reasonable, and none can be compared with the others. The platform has a price and no answer to what exactly it would prevent in a company of four. The test produces a report and no answer to who fixes what it finds. Touching nothing has a zero on the budget line and no estimate of what one bad Tuesday costs.
At this point a founder usually does one of two things: buys whatever looks most substantial, or postpones everything. Both decisions are made without the one number that matters, and that number is what this article is about.
#The question that sorts the list
How much security do we need has no answer. Security is not sold by weight, and after any purchase there is more to buy. A different question does have an answer.
The question
How much damage is left if an agent, an employee or a contractor gets it wrong tomorrow, with the basic limits already in place? Damage is counted in money, in customer data and in days of downtime, not in points.
This question has three useful properties. First, it moves the conversation from tools to consequences, and a founder understands consequences better than any engineer does. Second, it sorts the proposals at once: a measure that lowers the maximum damage ranks above a measure that adds a line to a report. Third, it shows where you may honestly stop. If, after the basic limits, the worst day costs the company one awkward email and two hours of work, a platform priced like a year of marketing adds nothing to that.
Postponing the question itself is expensive, and the cost builds quietly. Every month another tool is connected, another key is issued for now, another contractor is set up under the shared account. The maximum damage grows with the product while the budget for it stays at zero, because nobody has counted it. A year on, the question gets asked anyway: by a large customer in a questionnaire, by an investor in due diligence, or by an incident.
#What to pay for now
There is a short list of measures that cost days, not months, and bound the largest damage. They are not economised on at any company size. None of them is a purchase. All of them are made in your own server code and in the settings of what you already run.
-
Least privilege for every agent and service
A separate account per workflow, with access only to the objects that workflow needs. A support agent sees the ticket and the orders of one customer, not the customers table.
What it bounds: the size of any mistake. A shared administrative key turns a small error into the largest one available.
-
Separated environments and roles
Development, test and production live on different keys and different databases. The person or agent who writes code holds no production secrets and does not deploy on their own.
What it bounds: the path from an experiment to customer data. It stops being one step long.
-
Caps on volume and amount
A ceiling on operations per hour, on the amount of a refund, on the number of emails, on the size of an export. The server checks the cap, not the instructions given to the model.
What it bounds: scale. Most loud stories are one mistake applied to a thousand objects.
-
An action log
Who, when, through which tool, on which object. The log is written somewhere the agent itself cannot change.
What it bounds: time to detection and the cost of the investigation. Without a log an incident is reconstructed over weeks, by guesswork.
-
Approval of dangerous actions
Money, outbound email, deletion and permission changes go through a person. The approval request shows exactly what is about to happen.
What it bounds: the irreversible. It is the one class of action where a second pair of eyes always pays for itself.
-
Secrets on the server only
Keys for the payment provider, the mail service and the cloud never reach the text given to the model, the client application or the repository. The agent calls a server function, and the function knows the key.
What it bounds: leakage through text. A model cannot reveal what it never saw.
On a small product this list is closed in two or three weeks by one engineer. There is no subscription in it. That is why it gets skipped so often: nobody sells it, and there is nobody to send the invoice.
#Now, on a trigger, later
The remaining measures sort well along two axes. Vertically, the damage a measure bounds. Horizontally, what it costs: money, team time, and complexity that somebody will have to maintain afterwards.
The marked quadrant is never postponed. The dashed one may stay empty, provided the decision is written down and has a review date.
| Basket | What is in it | When to pay |
|---|---|---|
| Now | Permissions, separation, caps, the log, approvals, server-side secrets | Before the first user with real data |
| On a trigger | A sandbox for executing code, a shared tool gateway, one identity for agents, control of outbound connections | When a condition named in advance has fired |
| Later | A policy platform, an in-house monitoring centre, a dedicated team, formal certification | When a third team is rewriting the same rule, or a contract demands it |
The middle basket matters more than it looks. On a trigger does not mean some day. It means the condition is written down today and the money is spent on the day it is met. Without a written condition the middle basket quietly merges with the third.
#One workflow and five tools
A company of six sells a subscription to small shops. It has one agent and one workflow: triaging support tickets. There are five tools. The agent reads the ticket, reads the orders of that customer, drafts a reply, changes the status of an order and creates a task for a manager.
A contractor proposes a policy platform: a separate service, a rule language, a console, six weeks of integration. The founder asks what the platform would check. It turns out there are five rules. Only the orders of the customer in the ticket may be read. One order status may change per ticket. Refunds are not available to the agent at all. An email goes out after a person presses the button. Everything is logged.
Five rules fit into five server functions and forty lines of checks. An engineer does it in four days, and the rules sit next to the code they protect. The platform comes later, when there are ten agents and the rules start being copied from project to project.
Nothing here is a saving on security. The prohibitions stand exactly where they would stand with a platform: on the server, out of reach of the model. Only the way of managing them was postponed. Central control pays for itself through repetition, and one workflow has nothing to repeat.
#Where saving is not allowed
There are two areas where start simple does not work. Expensive tools are not required there either. It is only that a mistake in these areas gets no second attempt.
Irreversible actions. A money transfer, an email to a thousand addresses, deleted data, a changed account owner, a release to production. The shared sign is simple: there is no undo button. Before launch, every such action needs three things: approval by a person, a cap, and a log entry. That is cheap while there are five such actions. It is very expensive when there are fifty and nobody remembers half of them.
Sensitive data. Payment details, documents, medical and personal data, customer correspondence. Whether you will be breached is the secondary question here. What matters more is how many records one key can read in one go. What has been read cannot be returned. So the volume of reading is bounded as strictly as writing is: access one customer at a time, a ceiling on exports, a separate read-only copy of the database for analytics.
If your product has at least one of the two, the basic list of six stops being a recommendation. It becomes a condition of launch.
#When later arrives
I do not believe in thresholds such as after twenty employees or after the Series A. Company size predicts risk badly. A team of five holding payment data carries more risk than a team of fifty holding a catalogue of articles. What works is a trigger tied to the system itself.
Signs that plain server-side rules are no longer enough
One item that has fired is a reason to review the middle basket, not to buy everything at once.
- The same access rule is written in a third place, and the copies already differ. This is the moment a shared gateway becomes cheaper than three copies.
- The agent has started executing code or opening files that somebody outside sent in. That calls for isolated execution. A server-side permission check does not protect against it.
- Nobody can say within ten minutes which agents are running and on which keys. That calls for an agent registry and one identity. Without a list there is nothing to govern.
- A customer has appeared who sends a security questionnaire or asks for an auditor report. The requirement now comes from a contract. It is cheaper to prepare ahead than against a signing date.
- An agent has gained access to money, personal data or production infrastructure. The class of damage changed. Measures that were enough for drafts no longer match.
- An incident or a near miss that was found by chance and not through the log. Observability has fallen behind the system. That is fixed first.
#What a retrofit costs
Postponement has a price, and the price differs from measure to measure. A simple rule follows for what may be postponed. Postpone what can be added alongside later. Do not postpone what will later have to be built into the inside.
A policy platform is added alongside. If the rules already live on the server as separate functions, moving them into a shared service is one project and the product keeps running. Monitoring is added alongside too, provided the log is already being written.
Permissions are built into the inside. If every service has reached the database under one account for two years, narrowing the permissions means finding every place where the code silently relied on being allowed everything. On one project I watched that work take four months. In the first year it would have taken a week. The same is true of separating environments, and of secrets that have had time to spread across repositories, laptops and chat threads.
So there are two scenarios. In the first, the six basic measures are done now in three weeks, and the platform is bought eighteen months later, when it is needed. In the second, everything waits for the round. Before the round it turns out the investor runs a technical review. The team spends three months untangling shared keys in place of building the product, and the platform is bought in a hurry and placed on top of something it cannot fix. In money the second scenario costs several times more. In timing it usually lands on the least convenient quarter.
#Accepted risk on one page
Postponing a measure is normal. Postponing it and forgetting it is the mistake. The difference is one page of text, and a founder can keep it personally.
- Accepted risk
- A risk the owner knows about, has deliberately decided not to act on for now, and has recorded with a reason, a ceiling on the damage, a responsible person and a review date.
- In plain terms You know about the gap, decided not to close it yet, and wrote down why.
Each postponed measure needs one line of five fields. What has not been done. What happens in the worst case and what it would cost. Why that is acceptable now. Which trigger cancels the decision. Who reviews it and when. Ten lines take one page and five minutes to read, once a quarter.
The page does one more important thing. It separates we decided from we did not think about it. The first can be shown to a customer, an investor and a new technical lead. The second cannot be shown, because there is nothing to show.
#Three ways to spend it wrong
Security theatre: a forty-page policy, a badge on the website, a yearly test, and an agent running on the shared administrative key.
Instead Test every expense with one question: which specific action becomes impossible after it. If there is no answer, the money buys calm, not security.
Nothing until the round, because there are four of us and nobody is interested in us.
Instead An agent error and a dismissed contractor do not care about company size. The six basic measures cost three weeks. Their absence before a round costs three months and a discount on the valuation.
Buying a tool without an architectural problem: the platform was bought because large companies have one, and it holds five rules.
Instead Name the problem first: what repeats, what does not scale, what cannot be checked. A tool is chosen for a named problem. With no problem, the tool becomes one more system that nobody has time to run.
#How we decided this for ourselves
1ADK is itself built around an agent that reads somebody else's system, so we had to make this choice on ourselves. We have no policy platform. The rules live in server code, and there are not many of them.
An analysis job is bounded in advance. The agent only reads, runs nothing, no secrets end up in the result, paths are relative only, and the job expires. The text of a repository is treated as data, not as instructions. 1ADK does not require access to your repository and does not require you to upload source code to the service: the analysis is carried out by an agent on your side, and what reaches us is structured findings and evidence. That is a decision from the first basket. It bounds the maximum damage on our side, and it took no subscription.
Our third basket holds everything that pays for itself through repetition: a shared policy layer for many agents, a dedicated team, formal certification. It is recorded as postponed, with conditions for review. I say so plainly because an article about honest choices would be odd without an example of our own.
#What this approach does not give you
What this does not do
- It does not give you a universal budget. The share spent on security depends on the data and the actions in your product, and an honest figure for everybody does not exist.
- It does not replace what the law and your contracts require. If a regulator or a customer demands a specific measure, it moves to the first basket without a discussion about price.
- It does not protect against a breach of the infrastructure itself. The basic measures bound the damage from a mistake and from a stolen key to the reach of that key, and no further.
- It does not work without review. Baskets filled once describe a different company a year later.
Take a sheet of paper and list the actions in your system that cannot be undone. Next to each, write what stands today in the way of doing it by mistake. Where did you find a blank: next to money, outbound email, or the deletion of data?