Designing AI security in from the first line of code
Most AI security failures we see were decided in week one — where data flows, who holds the keys, what gets logged. Retrofitting is slow and expensive. Building it in from the start is neither.
Security is a design decision
Most of the AI security work we get called into is remedial. A system has been live for six months, a client's security team asks where the prompt logs are stored, and nobody has an answer. Retrofitting the answer took one team eleven weeks: tracing data flows, rewriting the logging layer, re-running vendor assessments. The same controls, designed in at the start, would have added perhaps four days to the build.
The reason is structural. An AI system's security posture is set by its earliest choices: which model endpoint it calls, where inference happens, what leaves the network, who can read the traces. None of these are code you can patch later without touching everything built on top. They are foundations. You either pour them correctly or you excavate.
What the first line decides
Before a feature exists, the first lines of a codebase decide four things. Where secrets live — in an environment file a contractor will eventually commit to a repository, or in a vault with rotation. What identity the system runs under — a shared service account, or a scoped one that an auditor can trace. Whether requests to the model are logged. And whether that log can be tampered with.
On a lead-management build for a property firm, we spent the first two days writing no features at all. We set up the secrets vault, the audit log, and the data classification for every field the CRM would hold — which columns held personal data under the DPDP Act, which could be sent to a model, which could not. Every feature after that inherited the rules. Nobody had to remember them.
Agentic systems raise the stakes. An agent that can write to a database or send an email is an employee without a manager. The first line of that code should define what it is allowed to touch, expressed as a permission list the client's own team can read and amend. If the allowed-actions list lives in prose in a design document, it does not exist.
Audit trails are a feature
When an agent misfires — quotes the wrong price, emails the wrong client — the first question is always the same: what exactly did it do, and why. If the answer takes a week of log archaeology, trust in the system dies regardless of the fix. We build every deployment so that any single action can be reconstructed in under fifteen minutes: the prompt, the model's response, the tool calls, the human approval if there was one.
That capability costs almost nothing on day one and a great deal on day two hundred. Structured logs with a request identifier that follows the whole chain are one afternoon's work in a fresh codebase. Bolted on later, they mean touching every integration, re-testing every hand-off, and explaining to the operations team why the dashboards changed. One government client's audit requirement — six years of retention, tamper-evident — was met by a configuration choice made before the first sprint.
Procurement will ask anyway
Indian enterprise and government procurement has caught up with AI faster than most builders expect. Tender documents now ask where inference happens, whether personal data crosses a border, who owns the fine-tuned weights, and what happens to embeddings when the contract ends. A team that designed security in answers these from its architecture diagram. A team that did not spends three weeks drafting answers and hoping nobody tests them.
Ownership is the question that decides deals. We have watched a public-sector evaluation eliminate two vendors in one afternoon because neither could state which entity held the encryption keys. The answer that survives scrutiny is boring: the client holds the keys, the client's tenancy holds the data, and the builder can demonstrate — not merely assert — that its own staff cannot read production records.
Security you can operate
A control that the night shift cannot use is decoration. Every security mechanism we ship comes with an operational answer: who gets paged, within what time, with what authority to act. On one mission-control deployment the target is simple — a suspicious agent action pages a named person within five minutes, and that person can freeze the agent without a developer on the call. Uptime commitments mean nothing if the freeze switch needs a code deploy.
The habit that makes all of this stick is unglamorous: treat the security requirements as the first user stories, not the last checklist. At XRISE we write them into the same backlog as the features, estimated and scheduled the same way. When security is a work item with an owner and a date, it ships. When it is a principle in a slide deck, it waits for the audit that finally makes it urgent — and by then it is excavation.
