The Agent Era Makes Boring Engineering More Important

Why the rise of autonomous AI agents like Seeka doesn’t replace foundational security, but actually makes traditional engineering principles more critical than ever.

There is something slightly strange happening in software engineering. We are giving software more autonomy at exactly the moment it has become easier than ever to build. That’s exciting: more people can turn an idea into working software, and experienced engineers can move considerably faster.

But while building Seeka, our autonomous data agent, and its underlying platform, Dataseka, we’ve found ourselves spending a surprising amount of time thinking about some very old and rather boring engineering problems. When you spend decades building systems in financial services, you learn that “making it work” is the easy part. The hard part is what happens when it doesn’t. You spend a lot of time thinking about what you’re trusting, who should have access, and what controls sit between an action and its consequences.

These aren’t particularly new ideas. NIST’s Zero Trust Architecture, for example, starts from the principle that systems should grant no implicit trust simply because something is inside a particular network or belongs to the organisation. Authentication and authorisation have to be established explicitly.1 We have carried some of that thinking into Dataseka. So as Seeka has become more capable, some of the questions we’ve been asking aren’t particularly futuristic: What happens when someone uploads a file that isn’t what it claims to be? Which inputs should an agent be allowed to trust? And how do you add all these controls without making the product slower for the people actually trying to use it?

If building in the agent era has taught us anything, it’s that boring engineering matters more now, not less.

One of the oldest rules in software is a useful place to start: don’t trust input from the client. OWASP recommends validating data from potentially untrusted sources as early as possible, ideally as soon as it enters the system.2 That principle predates LLMs by decades, but an application today might receive a prompt, a spreadsheet, retrieved content, an API response, the result of a tool call, or even the output of another agent. OWASP’s guidance for AI agents now says to treat user messages, retrieved documents, API responses and other external data as untrusted.3

We haven’t reduced the number of things software needs to distrust. We’ve dramatically increased it.

An upload is still an upload

A spreadsheet upload looks simple, but for Dataseka, it is still untrusted input arriving from a computer we don’t control. We don’t trust the .xlsx extension or the MIME type reported by the browser. OWASP recommends validating uploaded files and using multiple controls rather than relying on client-provided information.4

Our upload path looks roughly like this:

file = receive_upload()

if file.size > MAX_SIZE:
    reject()

detected_type = magika.identify(file)

if detected_type not in ALLOWED_TYPES:
    reject()

scan = clamav.scan(file)

if scan != CLEAN:
    quarantine()

process(file)

We use Google’s Magika to identify files by their actual byte contents, and ClamAV, the open-source antivirus engine, to scan them for known malware before they are allowed further into the application.5 6 These tools solve different problems. Magika helps us answer what is this file? while ClamAV helps us ask does it contain something we know to be malicious? Application rules still decide whether Dataseka accepts the file at all.

There is nothing particularly agentic about this code, and that’s what makes it interesting. Seeka may reason over information extracted from that file and decide which tools to use. But the decision about whether the file gets that far shouldn’t require reasoning. Use intelligence where intelligence helps. Keep guarantees in code.

The bots are getting smarter too

Bot protection is another old problem that AI is making more interesting. Scraping, fake accounts, credential attacks, and abusive traffic aren’t new. But the landscape changes when automation can interpret what it encounters, mimicking human workflow pacing or rendering complex headless browser sessions to seamlessly adapt to what it sees next.

Google is already responding to this shift. In 2026, it introduced Fraud Defense as the evolution of reCAPTCHA, describing an agentic web where legitimate AI agents increasingly operate alongside more sophisticated automated abuse.7 Dataseka uses reCAPTCHA as one layer of protection against automated traffic. Simplified, the decision might look something like this:

risk = recaptcha.assess(request)

if risk < BLOCK_THRESHOLD:
    block()

if risk < CHALLENGE_THRESHOLD:
    require_additional_verification()

continue_request()

The important part isn’t reCAPTCHA itself. It’s that a legitimate user and suspicious automation don’t necessarily need to follow the same path. That distinction becomes increasingly useful as the line between human and automated traffic gets less obvious.

Security shouldn’t make the product worse

There was a time when security and innovation were frequently discussed as opposing forces. Make something more secure and you add friction; add more validation and it becomes slower. That framing feels increasingly outdated. The interesting engineering problem today is not choosing between security or a good product. It is designing the system so legitimate users experience as little of the security machinery as possible while bad actors encounter increasingly more of it.

                 ┌─ low risk ─────→ continue normally
request → assess ┼─ uncertain ─────→ additional verification
                 └─ high risk ─────→ block

Order matters, too. There is little reason to run an expensive malware scan on a 2 GB file if the application only accepts 20 MB uploads - reject it first. Furthermore, architectural choices like asynchronous scanning are massive UX wins. If scanning happens asynchronously in the background, the application doesn’t need to make someone stare at a loading screen. The file simply remains unavailable to downstream processing until it is cleared, while the rest of the product remains snappy and responsive.

This is where security actually becomes an innovation problem: How do we make the controls stronger while making legitimate users notice them less? The goal shouldn’t be to make everyone prove they are legitimate at every step. It should be to make legitimate behaviour feel ordinary and malicious behaviour increasingly expensive.

Agents create more trust boundaries, not fewer

Uploads and bot traffic are relatively familiar problems, but agents introduce a more subtle change to system architecture. Consider a traditional application flow compared to an agentic one:

Traditional application

user → API → application → database


Agentic system

user
  ↓
agent
  ├── retrieved documents
  ├── memory
  ├── external APIs
  ├── tools
  └── other agents

Every new capability introduces another boundary where information enters the system or an action leaves it. OWASP’s current AI Agent Security guidance recommends treating external information as untrusted, applying least privilege to agent tools, validating structured outputs, and separating decision-making from execution for higher-risk actions.3

This leads to a principle we have found highly useful while building Seeka: The agent can decide what it wants to do, but the application decides what it is allowed to do.

action = agent.decide(context)

if not user.can(action):
    deny()

if not tool.allows(action):
    deny()

validate(action.arguments)

result = tool.execute(action)

The model isn’t the security boundary. The application is.

This matters because agents are probabilistic by design. We want Seeka to reason, interpret ambiguous questions, and decide how best to help someone. Those are exactly the places where a model is useful. However, whether a user has permission to access a dataset is not ambiguous. Neither is the maximum upload size, whether a file passed its malware scan, or whether an agent may execute a particular tool. Those belong in deterministic code.

Keep the boring parts boring

Not everything about AI security requires inventing a new category of attack. Bots, malicious uploads, API probing, and broken access controls are not new. AI just changes the economics of these attacks, making automation cheaper to create, easier to adapt, and capable of interpreting situations that previously required highly specialised code.

Because of this, some of the preparation for the agent era looks surprisingly familiar: validating inputs, limiting permissions, verifying identity, scanning files, rate limiting, logging important actions, monitoring unusual behaviour, and failing safely. The technology around those controls will evolve, but the reasons for having them haven’t changed very much.

Working in financial services for many years probably left us with a bias. When something becomes more capable, our first instinct isn’t only to ask what else it can do - we also start asking what else can go wrong. Building Seeka has reinforced that instinct.

There will absolutely be genuinely new security problems in the agent era. Prompt injection, agent identity, tool abuse, and cross-agent trust deserve new thinking. But we shouldn’t become so fascinated by the new problems that we forget the old lessons. Don’t trust input because an extension says it is a spreadsheet. Don’t trust a request simply because it looks like one a person would make. Don’t let a model decide whether someone has permission to perform an action.

And don’t make every legitimate user suffer because somebody else might be malicious. For a long time, security was treated as something that slowed innovation down. In the agent era, we should be aiming for the opposite: use better engineering, better detection, and better automation to make security stronger without making the product harder to use.

The smartest part of an AI product doesn’t always need to be the agent. Sometimes it is knowing which decisions should never be left to one.