AI is starting to touch evidence, money, customer data, business tools, and production code.
Before shipping AI, answer one question:
Can this AI be tricked, trusted, tested, and controlled?
Source: Stanford HAI AI Index 2026
If you ship AI in production, you should be able to explain each of these in one sentence to a non-technical stakeholder.
A public list of common risks for AI agents that can use tools, remember context, and act on their own.
Whether an AI agent can be tricked, misuse tools, overstep permissions, remember bad information, or take actions the owner did not approve.
If an AI agent can act inside a real product or company system, it needs limits before users rely on it.
A public list of common risks for apps built with large language models.
Whether a chatbot can be tricked, leak private data, expose hidden instructions, trust unsafe content, or use too much freedom.
Most AI apps start as chatboxes. They still need security rules before they touch real users or private data.
A public map of attack patterns used against AI systems.
How attackers try to trick, poison, steal from, or manipulate AI systems.
Builders need to know what real attacks look like before they decide what to test.
A voluntary guide many organizations use to manage AI risk.
Whether a team has a clear way to name, measure, review, and reduce AI risk.
It gives teams a shared process for deciding when AI is safe enough to use.
Most AI gets dangerous when you give it three things: tools it can use, memory it keeps, and data it can reach. This assistant has none of them on purpose, so there is nothing behind it to steal or hijack. Here is what it is hardened against, mapped to the OWASP LLM Top 10, with attack patterns named by MITRE ATLAS and risk handled the way the NIST AI Risk Management Framework suggests: name it, reduce it, review it.
Prompt injection is when someone buries hidden instructions inside normal-looking text to take over what the AI does; a jailbreak is coaxing it past its own rules. A separate fast screen reads every message before the assistant does. Anything adversarial gets a fixed lockdown reply with no AI model in the loop, so there is nothing to talk into breaking its rules.
Every assistant runs on private setup instructions that tell it how to behave, and attackers try to trick it into repeating them back. A secret marker is planted in those instructions. If it ever shows up in a reply, that reply is blocked before you see it.
Excessive agency means handing an AI more power than it needs: the ability to use tools, take actions, or keep memory. This one has none of that. It cannot use tools, take actions, or remember you between visits. Less power means less to abuse, and nothing to hijack into doing damage.
It is built to say "I don't know" instead of inventing an answer. Honesty is treated as a feature, not an afterthought.
Rate limits and input-size caps stop spam, abuse, and runaway bills, and idle counters are swept automatically so the limiter itself cannot be flooded.
Every reply passes through a cleaning step before it reaches your screen, so nothing unexpected slips through the output.
Secrets are the passwords and keys that let the service run, and a careless setup can leak them in an error page or status check. Internal endpoints are locked down, status checks reveal no keys or configuration, and standard security headers are set on every response.
Dependencies are the outside code building blocks an app relies on, and old ones carry known holes. Known-vulnerable packages are patched and pinned, and the dependency audit is kept clean.
Poisoning means slipping bad data into an AI while it learns, so it picks up the wrong lessons. Not applicable here: the assistant never trains on what visitors type, so there is no training set for anyone to poison.
Some assistants pull answers from a stored library of documents, and that library can be tampered with or mined for private data. Not applicable today: there is no document-retrieval database behind this one. That changes only if sourced answers are added later, and this page will say so when they are.
Self-reported against public frameworks, not a third-party audit or certification.
Three recent examples of why AI systems need limits before they touch tools, data, or code.
Microsoft disclosed vulnerabilities where prompt injection could cause an AI agent framework to run code on the machine hosting it.
If AI can use tools or run scripts, bad instructions can become real actions.
Do not let AI tools run commands freely. Limit what they can do, log what they do, and require approval for risky actions.
A rogue internal AI agent at Meta reportedly exposed sensitive company and user data to employees who did not have permission to access it.
Even internal AI tools can break approval boundaries if permissions are not tightly controlled.
AI agents that can share, publish, or access company data need strict limits and human approval.
Reports said an experimental AI agent tied to Alibaba-affiliated research used training resources to mine cryptocurrency during testing.
AI agents can behave in unexpected ways when their goals, tools, and limits are not controlled tightly enough.
Agents need containment, monitoring, and hard limits before they are given resources or system access.
Encryption is not one switch. Client data needs protecting in three different places, and the most common mistake is using the wrong tool for the job. Here is the short, correct version.
Scrambles stored data so a stolen database or backup is useless without the key. Most managed databases do this for you; the real job is confirming it is on and guarding the key.
Always serve over HTTPS. Never let client data travel over plain HTTP, even between your own services.
Passwords should be one-way hashed with bcrypt or argon2 and a unique salt. Never plain SHA-256, never MD5, never reversible encryption.
SHA-256 proves a file or message was not tampered with. It is a fingerprint, not encryption, and not a way to store passwords.
Encryption is only as strong as how you handle the key. Keep keys out of code and git, use a secrets manager or environment variables, and rotate them.
None of this is exotic. These are the operating rules I use.
OWASP Top 10 for Agentic Applications and the NIST AI Risk Management Framework are free, public, and the floor before any agent touches customer data, payments, tools, or production code.
No AI agent should reach real users without testing. If it can touch money, data, tools, or customer accounts, it needs stricter review.
If AI is part of a hiring, legal, medical, or financial decision, the person affected should be told and able to ask for human review.
If a company deploys AI to customers, it should assume responsibility for what the AI says and does. Do not blame the model when users are harmed.
Take over repetitive tasks, but leave judgment, review, and final decisions to people.
Independent researchers often find serious AI security issues. They need safe ways to report them.
Every load-bearing claim above traces to one of these public sources.
I build AI software that sets clear limits before AI touches customers, data, or production code.
Have a case study, a policy proposal, or a correction for this page? Same address: lukatasolutions@gmail.com.