AI security should not begin after the system has already been built.
LiteByte uses the UK National Cyber Security Centre's Guidelines for Secure AI System Development as a reference framework for designing, developing, deploying and operating AI-enabled software securely.
The guidance is particularly relevant to the way LiteByte builds AI systems because it is aimed primarily at organisations using externally hosted models, rather than assuming every organisation trains and operates its own foundation model.
For LiteByte, that creates a simple principle:
Secure the AI system we actually control: the application, data, prompts, permissions, integrations and operational environment around the model.
Security from the design stage
Security should influence the architecture, not simply test it afterwards.
The NCSC guidance treats security as a requirement throughout the AI lifecycle and divides its approach into four stages:
Secure design
Secure development
Secure deployment
Secure operation and maintenance
We consider security alongside functionality, performance, user experience, legal requirements and operational needs before development begins.
That means asking questions such as:
What information can reach the AI?
What external systems can it access?
What happens if the model behaves unexpectedly?
What happens if the AI provider becomes unavailable?
What could an attacker achieve if the AI component is successfully manipulated?
We secure the system around the model
Using a major AI provider does not remove the need to secure the finished application.
LiteByte will typically integrate established models from providers such as OpenAI, Anthropic, Microsoft or Google through APIs.
We therefore do not pretend to control:
- foundation-model training;
- training datasets;
- model weights;
- or the provider's underlying infrastructure.
Our focus is on the components we do control.
Depending on the system, that can include:
- prompts and AI configuration;
- client and user data;
- retrieval and knowledge sources;
- authentication;
- application permissions;
- tools and external actions;
- API credentials;
- model outputs;
- monitoring; and
- fallback behaviour.
The NCSC guidance explicitly recognises API-based AI development as a valid architecture and recommends security due diligence when choosing an external model provider.
External AI providers are security dependencies
A model provider is part of the system's supply chain.
We consider the security position of important external AI services rather than selecting a provider solely on model capability.
That can include reviewing:
- provider security information;
- the model/API being used;
- data handling;
- authentication;
- service availability;
- known limitations;
- and material changes to the service.
The NCSC guidance expects AI supply chains, including external APIs, software libraries, frameworks and models, to be assessed and monitored across the system lifecycle.
For important systems, we also consider what happens if that dependency becomes unavailable or no longer meets the required security criteria.
Control what leaves the application
An external model API sits outside the direct control of the application using it.
Before information is sent to an external AI service, we consider what the model actually needs to receive.
Depending on the use case, controls can include:
- authentication;
- data minimisation;
- restrictions on sensitive information;
- warnings or confirmation before sensitive content is transmitted;
- input validation;
- and clear rules about which data categories may be sent to an external service.
The NCSC specifically recommends appropriate controls over information sent to external AI APIs, particularly where potentially sensitive information may leave an organisation's direct control.
Secure by default
The safest configuration should not depend on every user becoming a security expert.
Where possible, we design AI functionality so that secure behaviour is the default.
That can include:
- least-privilege permissions;
- restricted tools;
- limited actions;
- secure API configuration;
- appropriate model-output guardrails;
- and potentially higher-risk functionality being deliberately enabled rather than silently available.
The NCSC guidance specifically recommends secure defaults, least privilege and making riskier capabilities explicit to users where they are necessary.
The principle is:
a user should not need to weaken the system before it becomes secure.
AI prompts and configuration are security assets
The AI layer contains assets that conventional software inventories can easily overlook.
These can include:
- system and developer prompts;
- AI configuration;
- retrieval rules;
- security assessments;
- logs and traces;
- evaluation information;
- model/provider configuration;
- and AI-specific documentation.
The NCSC guidance explicitly treats prompts, logs, software, data and AI assessments as assets that should be understood, protected, tracked and recoverable.
For LiteByte, important prompts and AI configuration should therefore be controlled and versioned in the same way that other security-relevant application configuration is controlled.
Document what we actually control
A third-party model does not remove the need for our own technical documentation.
We may not control the foundation model's training process, but we can document:
- which provider and model we use;
- what the AI is intended to do;
- important system prompts;
- retrieval behaviour;
- tools and actions;
- guardrails;
- known limitations;
- and significant failure modes.
The NCSC guidance recommends maintaining lifecycle documentation around models, datasets and system prompts, including scope, limitations, guardrails and known failure modes.
For an API-based LiteByte system, that responsibility applies primarily to our application layer and configuration, rather than attempting to recreate documentation owned by the foundation-model provider.
AI technical debt is made visible
Fast experimentation can create hidden security assumptions.
AI systems can accumulate technical debt quickly.
That might include:
- temporary prompt workarounds;
- temporary monitoring gaps;
- model aliases that are expected to change;
- manual controls intended to become automated;
- weak fallback behaviour;
- or known evaluation gaps.
The NCSC specifically recommends identifying and managing AI technical debt throughout the system lifecycle rather than allowing short-term engineering decisions to become permanent hidden risks.
Where technical debt has a material security consequence, we record it and give it an owner rather than allowing it to disappear into project history.
Deployment is a security decision
A working AI demo is not automatically ready for production.
Before release, relevant security controls should be implemented and appropriate evaluation completed.
Depending on the system, that can include:
- application security testing;
- AI-specific adversarial testing;
- prompt-injection testing;
- permissions testing;
- supplier checks;
- access-control review;
- and verification of secure production configuration.
The NCSC guidance recommends appropriate security evaluation before AI applications or systems are released and expects known limitations or failure modes to be communicated to users.
Users should understand their part of security
Secure AI often involves shared responsibility.
A client operating the finished system may control:
- who can use it;
- what information users provide;
- which integrations are enabled;
- how outputs are acted upon;
- and how the system is operated after handover.
Where relevant, we therefore provide information about:
- appropriate use;
- important limitations;
- riskier capabilities;
- security responsibilities;
- and how data may be processed by external AI services.
The NCSC guidance explicitly recommends making user responsibilities clear and explaining limitations, potential failure modes and relevant data handling.
We plan for incidents
AI security should not assume that compromise or unexpected behaviour is impossible.
Where relevant, AI systems are incorporated into the wider incident-response process.
That means considering scenarios such as:
- unexpected disclosure of sensitive information;
- successful manipulation of the AI;
- compromised credentials;
- provider security incidents;
- malicious use;
- or AI behaviour that creates an operational risk.
The NCSC guidance specifically recommends incorporating AI scenarios into incident response, escalation and remediation planning and retaining suitable audit information for investigation.
AI behaviour is monitored after launch
Deployment is not the end of the security lifecycle.
AI behaviour can change because of:
- model updates;
- provider changes;
- prompt changes;
- new retrieval information;
- new user behaviour;
- new attack techniques;
- or changes to the surrounding application.
Where appropriate, we monitor both the system's behaviour and its inputs so significant security-related changes or misuse can be identified.
The NCSC guidance explicitly covers monitoring AI behaviour and relevant inputs after deployment to support detection, investigation and remediation.
AI changes can behave like software releases
Changing the model can change the product even when the application code stays the same.
A new model version may respond differently.
A system-prompt change can alter behaviour.
A new retrieval source can change the information available to the AI.
A new tool can materially increase what the AI is capable of doing.
We therefore treat significant changes to models, prompts, data sources and AI capabilities as potential security reassessment and regression-testing triggers.
The NCSC specifically warns that changes to data, models or prompts can change system behaviour and recommends treating major updates as new versions where appropriate.
Security feedback improves the system
Security weaknesses should have somewhere to go.
Where LiteByte retains an operational role, relevant security concerns, unusual AI behaviour and vulnerability reports should have clear reporting routes.
The NCSC encourages organisations to maintain open channels for security feedback, respond to vulnerability reports and share relevant lessons where appropriate.
Those lessons can then influence future architecture, testing and development rather than being treated as isolated incidents.
Our secure AI lifecycle
For material AI functionality, our approach follows the lifecycle used by the NCSC guidance:
Secure design
Understand the architecture, external provider, data boundaries, permissions and security assumptions before development.
Secure development
Protect and document the AI-specific assets we control, manage suppliers and dependencies, and keep technical debt visible.
Secure deployment
Verify security controls, use secure defaults, evaluate the finished system and make responsibilities and limitations clear.
Secure operation
Monitor behaviour, control significant updates, respond to incidents and use security feedback to improve the system.
What this means at LiteByte
LiteByte uses the NCSC Guidelines for Secure AI System Development as a reference framework for secure-by-design AI engineering.
For our normal API-based AI systems, that means focusing on the security responsibilities we genuinely control:
- selecting appropriate AI providers;
- controlling what information is sent to them;
- using secure defaults;
- restricting AI permissions and actions;
- protecting and versioning prompts and configuration;
- managing AI-specific technical debt;
- testing before release;
- communicating limitations and responsibilities;
- monitoring material changes after deployment;
- and planning for failure rather than assuming it cannot happen.
The NCSC guidance works alongside our wider NIST AI RMF, ISO/IEC 42001, ISO/IEC 27001 and OWASP-aligned practices, with evidence reused where those areas overlap.