Confidentiality, Integrity, Availability and Authenticity

TL;DR: Confidentiality means only authorised parties can read something, integrity means nothing changes without authority, availability means the system works when it is needed, and authenticity means you can verify who or what produced a message. Every control protects one or more of these and leaves the others alone, so naming the property is how you find the gap. In AI systems, prompt injection is mostly an integrity failure that becomes a confidentiality failure, and runaway cost is an availability failure.

Four properties, four different questions

Security vocabulary is full of controls: encryption, signatures, access control lists, rate limits, backups. A beginner learns them as a list. An engineer learns them as answers to four questions, because each control answers some of the questions and is silent on the rest.

Confidentiality: who can read it? Data is confidential when only the parties entitled to it can read it. Encryption, access control and data minimisation protect it. A breach of confidentiality is a leak: a customer table exported, a system prompt revealed, another user's chat history shown in your session.

Integrity: who can change it? Data or behaviour has integrity when it changes only through authorised paths. Signatures, MACs, write permissions, code review and immutable logs protect it. A breach of integrity is tampering: a modified binary, a poisoned training set, an attacker's instruction followed as if the user had written it.

Availability: does it work when needed? A system is available when legitimate users can use it within an acceptable time. Redundancy, rate limits, capacity planning and backups protect it. A breach of availability is an outage or a cost so high the service is switched off.

Authenticity: who or what produced this? A message or artifact is authentic when you can verify its origin. Authentication of users, signatures on code and certificates on servers protect it. Authenticity is often folded into integrity, but keeping it separate is useful: a message can be unmodified and still come from the wrong sender.

A fifth property appears in many textbooks. Non-repudiation means the author of an action cannot credibly deny it later. Digital signatures with keys held by one party provide it; shared secrets cannot, because either holder could have produced the result. You will meet that distinction again when MACs and signatures are compared.

Name the property, find the gap

The habit worth building is to ask, for every control in a design, which property it protects. The answer exposes what is missing.

The last row matters for the rest of this curriculum. A filter on a model's output is placed after the model has read its context and decided what to do. If the model has already called a tool, the filter is looking at the wrong moment.

Beyond the triad: properties interviewers probe

Two extensions turn up in senior interviews because they resolve cases the triad handles badly.

STRIDE maps threats to properties. The 2006 Microsoft article that popularised STRIDE listed six properties and paired each threat with the property it violates: spoofing against authentication, tampering against integrity, repudiation against non-repudiation, information disclosure against confidentiality, denial of service against availability, and elevation of privilege against authorisation. The pairing is the bridge to the threat modelling lesson: find the threat, name the property, choose the control that protects that property. The same article noted that there is no integrity or availability API; properties are designed into a system, not called.

The Parkerian hexad adds possession and utility. Donn Parker argued in 1998 for six elements: confidentiality, possession or control, integrity, authenticity, availability and utility. The two additions explain incidents the triad describes awkwardly:

• A stolen laptop with full-disk encryption whose key is protected by a TPM and PIN: confidentiality holds, but possession is lost, and if it held the only copy of the files, so is availability.
• Data encrypted by ransomware and still physically present: the bytes are available, but their utility is gone until they are decrypted.

Privacy inverts one property. The LINDDUN privacy threat framework lists non-repudiation as a privacy threat: being able to tie an action to a specific person is exactly what a security audit log wants and what a privacy review may want to avoid. The usual resolution is to keep strong accountability for privileged and administrative actions and to minimise or pseudonymise it for ordinary user activity.

How AI systems stress each property

Confidentiality. Models read whatever enters their context and can repeat it. Retrieval that ignores the user's permissions, logs full of prompts, and conversation history shared across users all leak. Training adds a new channel: data used to train or fine-tune a model can sometimes be extracted from it later, and cannot be deleted without retraining.

Integrity. This is where AI changes the most. In conventional software, behaviour changes only when code changes. In an LLM application, behaviour also changes when the context changes, and the context includes text from strangers. Prompt injection is best understood as an integrity attack on behaviour. Poisoned training data and tampered model files are integrity attacks on the model itself.

Availability. Models are expensive per request. Long inputs, long outputs and agent loops that call tools repeatedly can exhaust budgets or capacity. OWASP's Top 10 for LLM Applications calls this unbounded consumption (LLM06:2026, LLM10:2025).

Authenticity. Generated text, images and audio make it cheaper to impersonate people, and models themselves are artifacts whose origin needs verifying before you run them. Signing models and checking provenance are authenticity controls.

Worked example: a ransomware incident by property

A company is hit by ransomware that encrypts 2 TB of file shares and, before encrypting, copies 40 GB of HR and finance documents out for double extortion.

The table prevents the most common post-incident mistake: declaring recovery when the backups are restored. Backups answered one property; the incident violated four.

Misconceptions interviewers listen for

• "Encryption gives integrity." Only authenticated encryption or a MAC does; CBC and CTR alone are malleable.
• "Signing hides the data." Signatures provide integrity and authenticity, not confidentiality.
• "Backups protect confidentiality." Backups are another copy to protect.
• "Availability isn't really security." In AI systems, cost exhaustion and agent loops are security failures with financial consequences.
• "HMAC-signed logs prove who did what." A shared key cannot provide non-repudiation.

How this shows up in interviews

The triad rarely appears as a definition question beyond the first screen. It appears as a reflex. When you propose a control, strong candidates say what it protects and what it leaves open: "TLS gives us confidentiality and integrity in transit, but the service still trusts any authenticated caller, so we need authorization on top." Interviewers listen for that second clause. In AI design rounds, labelling prompt injection as an integrity failure helps you pick controls that hold, because the question becomes "what can a manipulated model change?" rather than "how do we stop the manipulation?"

Say it in 30 seconds: "I name the property before the control. Confidentiality is who can read, integrity is who can change, availability is whether it works, and authenticity is who produced it. Each control protects some and not others: signing proves integrity but hides nothing, encryption hides but proves nothing. In LLM systems prompt injection is an integrity failure on behaviour that turns into a confidentiality failure, so I put controls on what a manipulated model can reach."