AI agent security, sealed before it ships

AI agent security is three controls doing one job: deciding what an autonomous system is allowed to touch, stopping it from being redirected by the data it reads, and keeping a record of everything it did. Kaishift applies all three to every agent, automation and pipeline we deploy. Permissions are scoped before the first run, injection defences are tested before launch, and the audit log lands on storage you own, readable without asking us.

What does AI agent security actually mean?

AI agent security is the set of controls that limit what an autonomous system can do (scoped permissions), stop untrusted input from redirecting it (prompt-injection defence), and prove what it did afterwards (audit logging). It covers the agent's access and its inputs as much as the code wrapped around it.

An agent is software with a budget of actions. Security is the work of setting that budget honestly, defending it, and recording the spend. It is the fifth floor of the five floors we run, and Amine Lamfichekh signs it off before anything reaches production.

Why do agents need different security from a normal web app?

Normal application security assumes the code decides. Paths are fixed, you review them once, and the review holds until someone changes the code. An agent decides at runtime, and it decides by reading text. Everything it reads is a candidate instruction: a support ticket, a PDF in the knowledge base, a page it fetched, a CRM field a stranger filled in.

The attacker does not need your password. They need to put a sentence somewhere your agent will read it. That is prompt injection, and no version number fixes it, because it follows from how the models work. The defensible position is to assume the model can be talked into anything, then keep "anything" small, reversible and visible.

How do you defend against prompt injection?

In layers. Each one is dull on its own. The stack is what holds.

• Untrusted by default. Retrieved content (documents, emails, web pages, tool output) enters the context marked as data. The system prompt does not take orders from the corpus.
• Nothing worth stealing in the context. Keys, tokens and credentials stay in your secret manager. A model cannot leak a secret it never saw.
• Tool allowlists. An agent calls the tools its job needs and nothing else. Adding one is a decision with your name on it.
• Read and write are separate. The agent reading untrusted content does not hold the write credential. It passes a structured, validated request to the one that does.
• Irreversible actions pause. Moving money, deleting records, mailing your customer list: a human confirms, and the confirmation is logged.
• Validated output. Anything leaving the model is checked against a schema before another system acts on it. Free text never becomes a query or a shell command.
• Adversarial tests before launch, kept afterwards. Injection payloads in every field an outsider can reach, re-run when the prompt changes and when the model version changes.

The same layers apply to a retrieval corpus, which is why RAG pipeline development and this floor are usually scoped together.

What do scoped permissions look like in practice?

Scoped means the agent has its own identity, and that identity does exactly one job.

• One service account per agent. A shared admin key or somebody's personal token defeats the whole design.
• A permission matrix written before the build: which agent, which system, read or write, which records. You approve it, and it becomes the thing we test against.
• Short-lived credentials, rotated on a schedule, stored in your vault.
• A kill switch you hold. Revoke the credential and the agent stops. You do not have to call us, and you do not have to wait for us. That is the practical half of why your automation should run on accounts you control.

An agent under these rules holds narrower access than the employee whose work it took over. That is the honest comparison, and it is usually the one that ends the argument.

What goes into the audit log?

Every action, in a form a non-technical reader can follow: timestamp, which agent, what triggered it, what it read, which tool it called with which arguments, what changed, and what came back. Refusals and failures are recorded the same way as successes. The storage is yours and the retention is your call.

Two reasons this earns its place. When something goes wrong you want the sequence of events rather than a theory about it. And when a client, an insurer or a regulator asks what your automated system did on a given day, the answer is a query someone runs in a minute.

What ships with every deployment

The seal is a fixed list, and none of it is optional:

• a written threat model for that system, one page, plain language
• the permission matrix, agreed before the build starts
• prompt-injection test results and the tests themselves, in your repo
• audit logging wired to your storage on day one
• a handover document: what runs, where, on which keys, and how to switch it off

The audit ships with the code, in the same delivery. You can walk all five floors in the tower to see where it sits against the rest of the work.

How does this line up with the EU AI Act and GDPR?

We are engineers, not your counsel. What we produce is the architecture and the evidence your counsel needs, and we would rather mark that boundary than sell certainty we cannot deliver.

Where the data lives is a separate decision from where the team sits. If your users are in Europe, the system deploys in an EU region and stays there. Morocco is the 55th state party to Convention 108 and its additional protocol, in force since 1 September 2019, which is the data-protection footing a European legal team usually checks before working with a team based here. It is not an EU adequacy decision, so any access from our side runs on standard contractual clauses with a data processing agreement behind it, in writing, rather than implying that geography handled it. Where processing stays in Morocco, law 09-08 and the CNDP apply as well. Our own privacy policy and terms are published alongside this page.

The EU AI Act reaches past the EU border: if the output of your system is used there, you are in scope. Sitting outside Europe is no exemption and we will not sell it as one. Which obligations bite, and from when, depends on how your system is classified, and the current dates are set out on our AI automation agency in Casablanca page. The groundwork we can do is real: data minimisation before anything leaves your systems, model providers on zero-retention terms where they offer them, a record of what the automated parts process, and logs detailed enough to reconstruct how a decision was reached.

Who this is for, and who it is not for

A good fit	A poor fit
You are giving agents access to real systems: CRM, mail, payments, production data	You want a badge for the website more than a control that works
Automations already run in your business and nobody can say what they can reach	You need an accredited ISO 27001 or SOC 2 report. We can prepare the technical evidence; the certificate is issued by an auditor
You want the security work on the same invoice as the build rather than a quarter later	You want a one-off penetration test with no system attached
Your customers sit in the EU and your operation does not	You want us to host it and hold the keys on your behalf. We do not do that

What it costs

No price list, on purpose. A five-person shop and a hundred-person operation do not carry the same risk, and three boxes would overcharge one and underserve the other. Bring the system you are unsure about. Thirty minutes on a call, then a scoped, priced roadmap in writing within 48 hours, yours to keep whether you sign or not. Your first deliverable lands inside two weeks, and those two weeks are refundable.

Security is the seal on the other four floors, so it usually arrives attached to something: AI agent development, a workflow automation build, or a handover of infrastructure someone else left undocumented. Longer write-ups on all of it sit on the blog.

Book a call. Free, thirty minutes, no commitment, two-week refund. Built in Casablanca, deployed on your accounts, wherever they are.

Common questions

Can prompt injection be prevented completely?

No, and anyone promising that is selling something. A model that reads text can be influenced by text. What you control is the damage: narrow permissions, no credentials in the context, separated read and write paths, a human confirmation on irreversible actions, and a log that shows exactly what happened. Contain it, test it, watch it.

Do you audit agents and automations you did not build?

Yes, and it is a common starting point. Something works, and nobody can say what access it holds any more. We map the credentials, the tools it can call and the data it reads, run injection payloads against every input an outsider can reach, then hand you a written threat model with the fixes ranked by blast radius.

Who holds the keys to the systems you secure?

You do, from day one. Every agent runs on your cloud, your repos and your API keys, under its own scoped service account. You can read the code, rotate the credentials and switch it off without contacting us. We build, operate and document it. We cannot lock you out of your own building.

Is it safe to give an AI agent access to production systems?

Scoped properly, it is safer than the equivalent human access, because it is narrower. An agent gets one identity, one job and a fixed tool list. A person gets a login that reaches everything their role touches. Add sandboxed actions and full audit logging and the agent is the more reviewable of the two.

Where is our data stored, and does it leave the EU?

Your choice, settled before anything is built. Systems serving EU users deploy in an EU region and stay there. Morocco has no EU adequacy decision, so any access from our side runs on standard contractual clauses with a data processing agreement. We take zero-retention terms with model providers wherever they are offered.