Every AI security debate eventually hits a wall. Not a technical wall - a philosophical one. We argue about prompt injection mitigations, model alignment techniques, and access control patterns. But beneath all of it are questions we have been dodging since we started shipping LLMs into production. I have been thinking about this while building vik.so and working through the security implications of AI agents at scale. The deeper I go into controls, the clearer it gets: some of the hardest problems are not technical.

You can't secure what you can't define

Here is the first brick wall: we do not have a shared security definition of an AI agent. Is it a tool? Then the human operating it is accountable for every output. Is it an autonomous actor? Then it needs its own identity, liability boundaries, least-privilege model, and audit trail. Is it somewhere in between? Where, exactly? This is not academic.

• Access control: If an agent is a tool, it inherits user permissions. If it is autonomous, it needs a separate principal and policy scope.
• Incident response: When an agent exfiltrates data via prompt injection, who is responsible - user, builder, operator, or model provider?
• Governance: ISO 27001 and NIST CSF map controls to assets, people, and processes. Agents blur all three simultaneously.

I ran into this directly building Control Mesh on vik.so. Frameworks assume clean categories. AI agents break those assumptions.

The epistemology problem

Epistemology is simply: how do you know what you know? LLMs do not "know" in a deterministic sense. They generate plausible language from statistical patterns. They do not reliably distinguish truth from high-confidence hallucination. In security, that changes everything:

• Trust boundaries: Zero trust says never trust, always verify. What does verification look like when there is no clean reasoning chain?
• Decision authority: If an AI agent triages alerts, summarises threat intelligence, or influences access decisions, every output carries epistemic risk.
• Audit trails: Traditional systems log deterministic causality. LLM systems produce probabilistic outcomes without simple, replayable cause chains.

The SQL injection analogy keeps coming back. In the 90s, we treated user input as trusted data. With LLMs, teams often treat model output as trusted knowledge. Same category of mistake, bigger blast radius.

The ethics gap in AI governance

Most AI governance programmes sound responsible on paper and vague in practice. The EU AI Act defines risk categories. NIST AI RMF provides management structure. ISO 42001 gives a certifiable management system. Useful foundations - but they still leave hard operational questions open:

• Whose ethics apply when systems operate across jurisdictions and cultures?
• Did users meaningfully consent to what an agent might do on their behalf?
• Who absorbs the "alignment tax" when safety slows delivery but market pressure accelerates it?

In Navigator on vik.so, I treat these as control design inputs, not abstract principles.

Determinism is dead

Traditional security programmes were built for deterministic systems: same input, same output, reproducible behaviour. LLMs break that contract by design. The same prompt can produce different outputs depending on context, temperature, model version, and hidden platform shifts. That is not a bug. It is the technology profile. Implications:

• Testing and validation: You can red-team and evaluate, but you are sampling a distribution, not proving a theorem.
• Compliance evidence: Auditors ask for consistent policy-constrained behaviour; your evidence model has to evolve.
• Incident reproduction: "Could not reproduce" becomes common, not exceptional.

If you cannot define failure conditions for an AI security control, you do not have a control yet. You have a hope.

What this means for builders

The technical decisions we make are already philosophical decisions. We should name them and design for them. What I would do:

• Treat AI agents as untrusted entities by default - not people, not simple tools, a separate category.
• Build epistemic checkpoints wherever AI output influences decisions.
• Translate governance principles into testable, enforceable release and runtime conditions.
• Accept non-determinism as a first-class security property.
• Explicitly map where framework assumptions (ISO 27001, NIST CSF) depend on predictable, human-operated systems.

Takeaway

The hardest AI security problems are not better firewalls or smarter detections. They are about assumptions: identity, knowledge, accountability, and trust. Those assumptions do not hold cleanly when the system can improvise. Philosophy is not a detour from AI security engineering. It is part of the substrate underneath it. The useful question is simple: which philosophical assumption in your AI security architecture worries you most right now?