AI SYSTEM SECURITY, IN DEVELOPMENT
The model is the attack surface.
U2 AI CyberTech works on the security of the AI system itself: the model, the data pipeline that feeds it, and the authority you hand to an agent. We are not a SOC, not network security and not a pentest shop. The service is in development and we are not delivering it yet.
In development, not delivered to anyone yet. Any timeframe here is a designed length of work, not a measured delivery time. No prices published. A U2 AI Studio Teknoloji A.S. company.
THE PROBLEM
An AI system fails in ways an application security review never looks for.
Organisations are putting AI systems into production faster than they are modelling how those systems fail. The threat model is genuinely different. The input is untrusted text that the model may read as instruction. The training and retrieval corpus is a supply chain of its own. An agent holding tool access can act with more authority than any human user was ever granted. A scan of the application wrapped around the model does not see any of that. Two public frameworks have now named the terrain instead of guessing at it: the OWASP Top 10 for LLM Applications 2025 ranks the failure classes, and MITRE ATLAS, at version 5.1.0 in November 2025, sets out 16 tactics and 84 techniques against AI systems, with agentic techniques added in February 2026. Both are voluntary frameworks and neither certifies anyone. We align our work with them; we hold no badge from them and will not claim one.
Ask how the model fails, not whether the firewall holds.
WHAT WE WORK ON
Six areas, one narrow focus
The service is in development and is not being offered yet, so there is no client list, no case study and no vulnerability count anywhere on this page. What follows is the work we are building, the public frameworks it follows, and the lines we settled on before taking a first engagement.
Prompt Injection Defence
INPUT SECURITY
- Direct injection comes from the person typing. Indirect injection arrives inside the content a model reads: a document, a support ticket, an email, a web page, a tool response. We look at both paths against the system as it is actually wired, not against the chat box alone.
- OWASP's Top 10 for LLM Applications puts prompt injection first for the second edition running, and the 2025 text is explicit that neither retrieval augmentation nor fine tuning fully removes this class. If someone has told you that RAG closed it, that is the document we would put on the table.
- So the work is defence in depth rather than one filter: least privilege on tool access, input and output handling reviewed as separate problems, human approval on high impact actions, and regular adversarial testing instead of a single pass at launch.
Data and Model Pipeline
SUPPLY CHAIN
- Poisoning of training and tuning data, examined wherever data enters: labelled sets, feedback loops, and user generated content that finds its way back into a later training run.
- Retrieval source trust. A RAG corpus is an input surface. We look at who can write into it, what strips instructions out of retrieved text before it reaches the model, and whether provenance survives all the way to the answer.
- Third party models and weights: where a checkpoint came from, whether it was verified against a published digest, what the licence actually permits, and what the loading path reaches out to at runtime.
Agentic Systems
AUTHORITY AND SCOPE
- An agent holding a tool is a system holding authority. In most agentic designs the damage we can model comes not from a clever exploit but from too much standing permission on a well behaved tool.
- We look at scope per tool, credential separation, what an agent may do without asking, the blast radius when one step in a chain is manipulated, and whether high impact actions stop for human approval rather than logging after the fact.
- MITRE ATLAS extended its coverage to agentic techniques in its 2026 updates, and that is the vocabulary we use for these reviews rather than a taxonomy of our own invention.
AI Red Team Testing
ADVERSARIAL TESTING
- No test runs without written, scoped authorisation. Articles 243 to 245 of the Turkish Penal Code make unauthorised access to an information system a criminal offence, and what makes testing lawful is the system owner's informed written consent. Consent cannot be implied, and a verbal go ahead is not consent.
- The authorisation names the scope, the IP ranges and the test dates. Acting outside it voids the consent that was given and creates both criminal exposure and a contract breach, which is why we stop at the boundary even when a tempting path sits one hop outside it. The line protects the client at least as much as it protects us.
- Threat modelling follows MITRE ATLAS tactics and techniques, which are structured like ATT&CK but specific to AI systems, read alongside the OWASP LLM Top 10. ATLAS is a voluntary framework with no certification scheme. We align our method with it; we are not certified against it, and no one is.
- Whose permission, not just yours. In most AI stacks the model, the hosting or a tool endpoint belongs to a third party, and a client cannot authorise testing against a system it does not own. Injection, extraction and jailbreak tests can reach that provider's infrastructure, where liability and the provider's own terms both survive your signature. We map ownership across the whole path first, work to each provider's published testing policy where one exists, and leave out of scope anything we cannot get authorisation for.
Where We Stop
SCOPE LIMITS
- We do not do classic cyber security. No SOC, no network security, no enterprise penetration testing outside the AI system itself. Our work begins at the model and the data path that feeds it.
- We do not address public administrations. Under Law 7545 public bodies procure cyber security products and services from parties authorised by the Cyber Security Directorate, and we hold no such authorisation. Our audience is the private sector.
- We issue no certificates and hold none. A security assessment is not an audit or an assurance engagement, and it is not a legal opinion. We also make no outcome guarantee: no one can honestly promise that a system will not be broken.
- We do not sell EU AI Act compliance. Regulation (EU) 2026/1744 deferred the Annex III high risk obligations to 2 December 2027 and the Annex I ones to 2 August 2028, so Article 15 binds no one today, and conformity assessment would not be ours to perform in any case. The preparation window is open; the obligation is not.
- If personal data is breached, the notification duty sits with the data controller, which is the client. The Board's decision 2019/10 reads the statutory shortest time as 72 hours. We can prepare the evidence and the readiness behind that clock, but we do not notify on anyone's behalf.
Designed Work Lengths
ENGAGEMENT SHAPE
- We publish durations and no prices. These are designed work lengths: how long each engagement has been built to run, not a delivery time we have measured, because we have not delivered one yet. Scope changes them, and the authorisation carries the dates that count.
- As designed: scoping and threat modelling, about two weeks. A focused assessment of a single AI application, about three to four weeks. An agentic system review, about four to six weeks. The only dates that bind anything are the ones written into the authorisation.
- Test data, extracted samples and any client material we hold are destroyed when the engagement closes, on a schedule written into the contract rather than left to habit.
- Client data, prompts and models are never used for our own purposes. Not for training, not for tuning, not as an evaluation set, and not carried into anyone else's engagement.
HOW IT WORKS
Four stages, and the first one is paperwork
Scope and written authorisation
Before anything is touched we agree in writing what is in scope: the systems and models, the IP ranges, the accounts, the test dates and the rules of engagement, including what happens if we find a path leading outside that list. One point decides more of these engagements than any other: authorisation has to cover every system the test will actually reach, and in an AI stack that is rarely one party. Where the model, the hosting, the retrieval store or a tool endpoint belongs to a provider, the client cannot consent on that provider's behalf. We map who owns each system in the path, and each owner's authorisation or published testing policy has to be in hand before anything runs. Where it cannot be obtained, that system stays out of scope.
Threat modelling
We map the system as built: where inputs enter, what the model can read, which tools it can call, what credentials sit behind those tools, and where trust boundaries are assumed rather than enforced. Tactics and techniques come from MITRE ATLAS, read alongside the OWASP LLM Top 10, so the model is written in vocabulary the client can check against public sources instead of taking on our word. The output is a ranked set of scenarios we intend to test, agreed before testing starts.
Testing
Adversarial testing inside the agreed scope: direct and indirect injection against the real input surfaces, attempts at data and system prompt extraction, retrieval poisoning against sources the system trusts, tool abuse and privilege escalation in agentic flows. Testing runs on the dates named in the authorisation, with a named contact reachable throughout. When a live path leaves the agreed scope we stop and come back for a written extension rather than following it, because acting outside scope voids the consent that made the work lawful.
Reporting and handover
Findings are written to be reproduced: what was done, what the system did, why it matters, and what would change the outcome. Each one carries a concrete remediation direction and a severity we can defend, with the residual risk stated plainly where a fix is partial. We walk the engineering team through it, retest what has been fixed if that is agreed, and destroy the test data. What we hand over is evidence and a plan; the decisions, the filings and any regulatory notification remain the client's to make.
WHO WE BUILD FOR
Four situations, all of them commercial.
Every organisation below is a private company. We do not address public administrations: under Law No. 7545 public bodies procure cyber security products and services from parties authorised by the Cyber Security Directorate, and we hold no such authorisation, so we stay out of that arena entirely. Each case names the threat we would look for and the artefact you would receive. None of them names a customer, because we do not have one yet.
Software teams shipping an AI product
You have a language model feature in front of paying users: a chat surface, a document assistant, a copilot inside your own product. The threat we start with is prompt injection, listed first in the OWASP Top 10 for LLM Applications 2025 for the second edition running, and that report is blunt that neither retrieval augmentation nor fine tuning fully removes the class. We look at direct injection through the user's own input, indirect injection through a document or a page your retriever pulls in, and injection that reaches a tool call and turns into an action. What you would receive: a written threat model of the feature, adversarial test cases run only against systems named in the authorisation, and a findings note that keeps what we reproduced separate from what we only suspect.
Enterprises rolling out internal AI tools
An assistant over the intranet, a retrieval corpus built from years of internal documents, a model wired into ticketing or HR. The failure here is rarely dramatic. It is a payroll file indexed into a corpus every employee can query, a retrieval path that quietly crosses a permission boundary, an ingestion pipeline nobody vets that lets poisoned content into the index, and prompt and output logs kept far longer than anyone intended. What you would receive: a data boundary map from source document to rendered answer, the list of retrieval paths that cross an access boundary, a review of how outputs are handled downstream, and a retention note on prompt and output logging. Personal data stays yours throughout, and so does the controller responsibility that comes with it.
Teams building agentic and automation systems
The moment a model can call tools, a text problem becomes an action problem. Excessive agency is the recurring shape: an agent holding a token far broader than its job needs, a chain of steps that reaches a payment, a deletion or an outbound message with no person in the loop, a subagent inheriting permissions it was never meant to hold. MITRE ATLAS reached 16 tactics, 84 techniques, 32 mitigations and 42 case studies in version 5.1.0 in November 2025, and its February 2026 updates added agentic techniques specifically. What you would receive: an inventory of every tool the agent can reach with a least privilege recommendation per tool, the list of actions we think should require human approval, and adversarial scenarios where an injected instruction is followed to a real world effect.
Technology teams assessing an AI vendor
You are not building the model, you are buying it, and procurement is asking whether it is safe to sign. The exposure sits in the supply chain: where the model and its training data came from, which third party plugins and extensions ride along, how updates arrive and whether a silent model change can alter behaviour you tested. What you would receive: a question set written for that specific vendor with the evidence each answer should be backed by, a mapping of the answers onto OWASP Top 10 for LLM Applications 2025 and MITRE ATLAS, and a plain statement of what stayed unknown after asking. This is a technical review for your own decision. It is not an audit, not an assurance engagement and not a legal opinion, and it does not certify the vendor.
WHAT YOU CAN HOLD US TO
Four things we will not blur.
We say it on the first screen: this is in development
The service is not being delivered yet. That is why this page carries no customer name, no case study, no count of vulnerabilities found, no measured result and no logo wall. All of it would be borrowed credibility and it collapses at the first serious question. Saying it at the top costs us some enquiries and keeps the ones worth having, and it means everything else you read here can be taken at face value.
No written authorisation, no test. Ever.
Articles 243 to 245 of the Turkish Penal Code make unauthorised access to an information system, and remaining in one, a criminal offence. What makes security testing lawful is the informed, written consent of the system owner. Consent cannot be implied, inferred from a conversation, or assumed because someone senior nodded. The contract has to name the scope, the IP ranges and the test dates. We hold that line for a reason that is yours as much as ours: action outside the agreed scope voids the consent it depended on, which creates criminal exposure and a breach of contract at the same time, and good intentions do not cure it. Stopping at the boundary is not caution, it is the thing that keeps you covered.
AI specific, and we do not sell classic cyber security
No SOC, no network security, no corporate penetration testing. Our subject is the model and the data pipeline around it: prompt injection direct and indirect, model and corpus poisoning, training and retrieval data leakage, the AI supply chain, excessive agency in agentic systems, and red teaming designed for AI behaviour rather than for infrastructure. That narrowness is deliberate. It keeps us out of a crowded market we would be an average participant in, and it puts us next to the sister brands doing proof of concept and advisory work on the same systems, so the security view arrives while the system is still being shaped rather than after it ships. There is a side of that worth stating plainly. u2aipoc.com and u2aiconsulting.com are brands of the same company and may have built or advised on the very system in question. Reviewing the security of something our own group built is a conflict of interest. Where that arises we disclose it in writing at the start, and the client decides who should carry out the review.
Aligned with frameworks, certified by none
We work to the OWASP Top 10 for LLM Applications 2025, MITRE ATLAS and the NIST AI Risk Management Framework. These are voluntary frameworks. ATLAS has no certification scheme at all, so nobody can be certified against it, and we hold no ISO 27001 certificate and no TURKAK accreditation. We say aligned, we do not say certified, and we will not imply approval by any authority or body. The same discipline applies to the EU AI Act: the high risk obligations under Article 15 have been postponed, so we describe today's picture as a preparation window rather than telling you a rule already binds you.
GET IN TOUCH
Tell us what your AI system does
The service is in development, so the honest invitation is not a sales meeting. Tell us what you are building and where the model sits in it. We are deciding what to build first, and the systems people are actually shipping decide that better than we can from the outside. If your system is something we are not ready for, we will say so rather than book a call.
Thanks. We'll get back to you within one business day.
FAQ
Frequently asked questions
Can we buy this service today?
No. U2 AI CyberTech is in development and the service is not being delivered yet. There is no client to name, no case study, no vulnerability count and no measured result anywhere on this site, because none of that exists. We would rather say so on the first screen than let you discover it in a meeting. What we can show is the scope we are designing, the frameworks we work in alignment with, and the rules we intend to work under. If the subject is relevant to you, write to us and we will tell you plainly where the work stands.
Do you do classic cyber security, SOC monitoring or corporate penetration testing?
No. Our subject is the security of artificial intelligence systems: the model, the training and retrieval data path, the tools an agent is permitted to call, and the supply chain behind all three. Prompt injection, model and data poisoning, training data leakage, AI supply chain exposure and excessive agency in agentic systems are the classes we work on. Network security, endpoint monitoring and general enterprise penetration testing are a different discipline with established providers, and we do not present ourselves as being in that market.
What do you need before a single test is run?
A written authorisation that names the scope. Articles 243 to 245 of the Turkish Penal Code make unauthorised access to an information system a criminal offence, and what makes a security test lawful is the informed, written consent of the system owner. Consent cannot be implied. The agreement has to state the systems in scope, the IP ranges and the test dates. Anything performed outside that scope invalidates the consent that was given and creates criminal exposure as well as a breach of contract. So we stop at the line, and that limit protects you at least as much as it protects us. One thing surprises people: your authorisation only covers what you own. If the model runs on a provider's platform, or retrieval sits in someone else's service, that provider's permission or published testing policy is needed as well. We establish who owns each system in the path during scoping, and anything without authorisation stays out of scope rather than being tested quietly.
Does the EU AI Act bind us today?
Not in the way it is often sold. Article 15, which sets accuracy, robustness and cyber security requirements for high risk systems, is not in application yet: Regulation (EU) 2026/1744, the Digital Omnibus, moved the standalone Annex III high risk obligations to 2 December 2027 and the Annex I product embedded ones to 2 August 2028. What applies today is the Article 5 prohibitions and the Article 4 literacy duty since 2 February 2025, the general purpose AI chapter since 2 August 2025, and the Article 50 transparency duties since 2 August 2026. We are not a conformity assessment body and we do not determine anyone's compliance. The honest reading is that the timetable moved and the preparation window is open.
Do you issue a certificate at the end?
No, and for this subject nobody else issues one either. The OWASP Top 10 for LLM Applications and MITRE ATLAS are voluntary frameworks, and ATLAS has no certification scheme at all. We hold no ISO 27001 certificate, no accreditation and no authorisation from any body, and we will not imply one. What we can do is work in alignment with those frameworks and state which entry or technique a finding maps to. Alignment describes a method. It is not a certificate, it is not an audit, and it is not an assurance opinion.
If there is a data breach, do you notify the authority for us?
No. Under Turkish data protection law the notification duty belongs to the data controller, which is you. The Board decision 2019/10 of 24 January 2019 reads the statutory wording as 72 hours from the moment the controller becomes aware of the breach, and decision 2019/271 of 18 September 2019 sets the minimum content of the notice given to the affected person. What we can do is prepare the ground: evidence, timeline, technical description and the material a notification needs, written in plain language. The filing itself stays with you, because the obligation does.
Why are there durations on this page but no prices?
The durations here are designed lengths of work, not measured delivery times. Nothing has been delivered yet, so we hold no delivery record to publish and we will not dress a plan up as a track record. A designed length tells you how a piece of work is shaped: how long a review is meant to run and what is meant to fit inside it. Price depends on the systems in scope, the environment and the access model, so it belongs in a written proposal for a specific scope rather than on a web page.
What happens to our test data and our model?
They stay yours. We do not use client data, prompts, documents, model weights or findings for our own purposes, and we do not use them to train or improve anything of ours. Test data, copies, exported artefacts and working material are destroyed when the work ends, and anything retained is limited to what the agreement says is retained and for how long. Handling, storage location, access and destruction are written into the agreement before the work starts, not negotiated afterwards.