Apple AI Security Engineer interview questions

Privacy principles become engineering decisions about fields, retention and contracts. The scored answer walks one feature and makes each principle concrete.

Most candidates say 'rings' and stop. The interviewer is listening for who enforces the boundary, where the kernel must distrust its caller, and why one kernel bug undoes every process boundary at once.

Isolation is enforced by page tables and credentials, then deliberately punched through by debuggers, shared memory and IPC. A strong answer names both the wall and the doors.

Reading rwx bits is the easy half. Interviewers check whether you know what execute means on a directory, why setuid binaries are an attack surface, and what the sticky bit does and does not protect.

Everyone knows MAC is 'stricter'. The scored part is why a compromised root process can still be confined, how labels differ from paths, and what you do when the policy blocks production at 2am.

Check, then use: two system calls, and an attacker in between. The answer interviewers want replaces names with handles and checks with atomic operations, and can show it in code.

OpenSSH's design is the model answer, but interviewers want you to derive it: what the parser must never hold, how small the privileged half can get, and the three mistakes that make a privilege drop reversible.

Programs rarely name the file they run or load; they search for it. Whoever can write earlier in the search order chooses the code. The answer covers both platforms and the one rule that fixes both.

Interviewers listen for precision: an overflow is an out-of-bounds write, an over-read is a different bug, and a use-after-free is about lifetime, not bounds. Getting the taxonomy right is most of the easy question.

Reciting the acronyms is the easy part. The scored answer pairs each mitigation with the exploitation step it blocks and the precondition that defeats it, which is why they only work together.

Once data could not run as code, attackers stopped bringing code. The interview checks that you understand code reuse as an idea, and what forward-edge and backward-edge protections each enforce.

'It's just a crash' and 'mitigations are on' are the two answers that get candidates marked down. The scored answer separates the primitive, the reachability and the privilege, and treats a read bug as half of an exploit.

'Rewrite it in Rust' is a slogan, not a plan. The staff answer ranks components by exposure, stops new bugs at the boundary first, and keeps the old code contained while the language mix shifts.

Random input finds shallow bugs. Coverage feedback, sanitizers and a harness that reaches the parser are what make fuzzing find the deep ones. The interview checks all three, plus what happens after the crash.

Tool names are not the answer. Interviewers want to know what each view can and cannot tell you, and why a decompiler's output is a hypothesis to be checked at runtime.

Interviewers give an unfamiliar binary to see method, not stamina. Start from the question, find the code that touches the secret through imports and strings, confirm at runtime, and report what you proved and what you did not.

A bypass screenshot is not a finding. Interviewers look for whether you can separate 'I changed my own copy of the program' from 'I can now do something the server should have stopped'.

The CPU does work it later throws away, but the cache remembers. The strong answer explains that one sentence precisely, then turns it into isolation decisions for shared infrastructure.

Secure Boot refuses to run unsigned code; measured boot records what did run; a TPM lets someone else check that record. Candidates who blur the three cannot reason about attestation at all.

Every obfuscation must still run on the CPU in a form the CPU understands. That single fact tells you how each one is undone, and why obfuscation buys time rather than secrecy.

A single check is a single patch. The design question is how to make removing protection expensive, detectable at scale, and pointless because the server holds the real decisions.

EDR products, profilers, game cheats and banking trojans all use the same trick: make a call to function A run your code first. Knowing the mechanics tells you both how to detect it and why user-mode hooks are a weak place for security controls.

The algorithm is correct and the key never leaves the chip. The attacker reads it anyway from how long, how loud or how hot the computation is, or breaks it by making the chip skip one instruction.

All three face the same impossible brief: let the user's device use a secret without letting the user have it. The good designs change the brief instead of pretending to meet it.

Most Mac compromises do not break these controls. They persuade the user to step around them, or borrow the permissions of an app that already has them.

'It's signed' means different things depending on when the signature is checked: once at install, every time the binary loads, or on every page of memory as it executes.

Browsers assume the JavaScript engine will be exploited. The architecture is built so that one bug buys an attacker a locked room, and they need a second, different bug to leave it.

W^X says memory is writable or executable, never both. A JIT compiler's whole job is writing code and then running it. How a runtime squares that circle decides how much an attacker gains from a memory bug.

Typing a command sets off a chain: a system call, a permission check, a loader, dynamic linking and memory protections. Every step is a place security is enforced, and a place it can be bypassed.

On macOS, root is not enough to read a user's documents or watch the screen. TCC decides that, and XPC is how privileged helpers talk, so both are prime targets.

A crash is not an exploit. Turning one into the other takes several steps, and every modern mitigation is designed to break one of them.

The kernel is the single shared authority on a machine. A bug there means any process can rewrite who it is.

A patch is a map to the bug it fixes. The interview question is what that means for disclosure timing, open-source fixes and your own patch deadlines.

Default-deny execution is one of the strongest endpoint controls there is, and one of the least deployed. The scored answer explains the rule types, the bypass classes and how to roll it out without a revolt.

The classic 'what happens when you type google.com' turned into a security question. Interviewers want the stack in order, with the attacker who sits at each layer and the control that removes them.

Users type a domain, not https://. That one habit gave attackers a plain-HTTP first request to hijack. HSTS closes it, and preloading closes it before the first visit, with a commitment you cannot easily undo.

Every TLS error is a specific check failing. Engineers who can name which check, from the chain the client actually saw, fix outages in minutes and never 'fix' them by turning validation off.

Pinning trades availability for a narrower trust set. The answer that scores compares each pin target by what it survives, and uses HPKP's retirement as evidence of what goes wrong.

A shared password, a capture of one handshake and an offline dictionary is still how many Wi-Fi networks fall. The answer explains why, what SAE changed, and why enterprises use certificates instead.

A MAC address is a label the device chooses and announces in clear text on every frame. The answer turns on that one fact, and on what a network should check instead.

Short-range radio assumes that being close means being trusted. The scored answer explains pairing models, key negotiation bugs and why relays need distance measurement, not stronger encryption.

The trap is answering 'which is better'. Every protocol you use daily runs both, each doing the job the other cannot.

Message names are table stakes. The interviewer is listening for why CertificateVerify exists and what Finished actually checks.

Checking the signature is one step of seven. The bugs that matter live in the other six, and in code that switches validation off.

The question behind the question: if your server's private key leaks next year, what happens to the traffic someone recorded today?

Encryption without integrity has been exploited for decades. Nonce reuse under GCM is worse than most candidates think: it breaks integrity too.

Revocation asks every client to check a third party on every connection, and most clients quietly do not. The scored answer explains each mechanism's failure mode and why the industry is moving to short lifetimes.

A classic that tests whether you know how hash functions work inside. The scored answer explains length extension, the nested HMAC construction, and how to verify a MAC safely.

Encryption hides content, not length. The scored answer shows how compression turns length into a leak when secrets and attacker text share a message, and where that bites today.

Most cryptographic failures are misuse of good primitives, not broken algorithms. The scored answer has a checklist that catches the common ones and a strong default to replace them.

Cryptography assumes unpredictable numbers, and real systems have repeatedly failed to supply them. The scored answer gives the causes, the famous failures, and the rules that prevent repeats.

Both keep keys out of application memory; they differ in who you must trust and what you can prove. The scored answer chooses by threat model and requirement, not by fashion.

Trusted execution moves the trust boundary from the operator to the hardware and the attested code. The scored answer is precise about what that protects, what it assumes, and what it leaves open.

Using one key for several purposes quietly couples their security. The scored answer explains extract and expand, shows key separation by context, and says when HKDF is the wrong tool.

Data encrypted today can be recorded and decrypted when a capable quantum computer exists. The scored answer prioritises by how long data must stay secret, starts with key exchange, and builds crypto agility.

A small root hash that commits to millions of entries. The scored answer builds an inclusion proof, explains consistency proofs, and names the systems that depend on them.

The response differs sharply between a signing key and an encryption key. The scored answer contains use, rotates, revokes trust, assesses what the attacker could forge or read, and repairs what depended on it.

Preimage, second preimage and collision resistance sound alike and protect different things. The birthday bound explains why the last one costs half the bits.

Issuing a certificate is easy. Knowing every certificate you issued, renewing them before they expire, and surviving the day a CA key leaks is the design.

Being able to switch algorithms is essential. Letting an attacker choose which algorithm you switch to is a vulnerability with a long history.

A certificate is a signed statement with a short list of claims: this key, these names, these uses, this period, issued by this CA. Every validation failure you have seen is one of those claims not holding.

There is no single list of trusted roots. Browsers, operating systems, language runtimes and container images each carry their own, updated on their own schedules, and production outages follow from the differences.

Domain-validated certificates prove one thing: whoever asked could answer a challenge on that domain at that moment. Every attack on issuance is a way to answer that challenge without owning the domain.

An HSM's promise is narrow and strong: the key cannot leave in plaintext. Everything else, including who may ask the HSM to use the key, is your design.

They all promise 'hardware security'. They protect different things from different attackers, and choosing well means knowing who you are defending against.

A certificate is a CA's signature over a structured statement about your key. Each step from key to padlock exists to stop one specific lie.

The root key is the one thing you can never easily replace, so it signs almost nothing. Everything about intermediates follows from that.

Both are 'something you have'. One can be typed into a fake page in real time; the other checks which page is asking.

Most OAuth breaches come from a few well-known mistakes. The scored answer explains each attack and the specific rule that stops it, as consolidated in the 2025 OAuth security best current practice.

The user never types anything an attacker could replay, and the browser, not the user, decides which site is asking. Those two facts are the whole phishing story; the ceremony is how they are enforced.

Liveness checks were built to catch a photo held up to a camera. Deepfakes often never go near the camera at all.

A strict CSP blocks many XSS payloads but not all, and DOM XSS has paths it cannot see. The scored answer explains what a nonce-based policy stops, where it fails, and why Trusted Types targets the DOM sinks.

Logging in is one moment; a session lasts hours or months. Most session bugs live in what happens between: identifiers that never change, timeouts nobody enforces, and logouts that only clear the browser.

The login form is the front door, but attackers use the side doors: reused passwords, guessable recovery, and MFA that can be phished or reset by a support agent.

Both platforms sandbox apps and require signing; they differ in who decides what runs and how fast fixes arrive. Interviewers want the shared model first, then the differences that change a threat model.

A standard is a checklist only if you use it badly. The answer interviewers want maps the app's data and threats onto MASVS areas, then picks which MASTG tests are worth the time.

'Use the Keychain' is half an answer. Interviewers check whether you know the key never leaves the hardware, the data it protects still does, and which settings stop it riding along in a backup.

Any app can claim myapp://. That single fact breaks OAuth redirects, password-reset links and payment flows that trust a custom scheme. The fix is a link the operating system verifies against your domain.

A WebView puts a browser inside your app, without the browser's address bar, and often with a bridge to native code. XSS in that page is no longer 'just XSS'.

The token is safely in the Keychain, and also in the crash log, the analytics payload and the app-switcher screenshot. Interviewers want the list of side doors, not the front door again.

The device is in the attacker's hand in half the scenarios. A strong model sorts threats by where the attacker sits, then puts every decision that moves money behind a check the phone cannot fake.

Pinning narrows trust, and every outage story about it is a rotation story. The scored answer decides whether to pin at all, pins public keys with backups, and plans for the release that can never update.

Two different questions hide here: does the app validate TLS at all, and does it pin? Testers who merge them either miss the critical bug or report a non-issue as one.

Detection that runs on the attacker's device reports whatever the attacker allows it to. Interviewers want to hear what it is still good for, and what it must never decide alone.

Attestation gives your server a signed statement it did not have to trust the client for. The design question is what that statement covers, how you bind it to a request, and what you do when it is missing.

Anything in the app binary belongs to whoever downloads it. The strong answer stops trying to hide a client secret and builds on user tokens, PKCE, device-bound keys and server-side limits.

Unzip, decompile, read the manifest, then watch it run. The interview checks whether you know where the interesting parts of an app hide, and that obfuscation changes your effort, not your conclusions.

Moving a secret into C changes who can find it in an afternoon, not whether it can be found. The scored answer shows how an analyst would recover it, then replaces the design with one that does not need a shared secret.

No shield is unbreakable, so 'can it be bypassed' is the wrong test. Measure how much it raises an attacker's cost on the threats you actually face, and what it costs you in crashes, performance and false positives.

Everything shipped on the phone belongs to the person holding it: the weights, the system prompt and any key the assistant uses. And the assistant now reads notifications, messages and screens written by strangers.

Pinning protects the user from the network. It was never going to protect your API from the person holding the phone, and the good answer explains both halves.

Both platforms let an app declare its transport rules in a file the reviewer can read in seconds. Knowing which lines are dangerous makes you fast in a mobile review.

A key the app cannot export is only half the story. The other half is making the key usable only after the user is really present, which a hooked 'authentication succeeded' callback can fake.

On a phone, the signing key is the app's identity: it decides who can ship updates, which data the app can share, and what it is entitled to do. Lose it, or let someone else sign, and that identity changes hands.

Rooting is not one trick. It is a decision about the boot chain: either the owner unlocks it, or an exploit breaks it. Everything an app can detect follows from which.

Most mobile findings do not need root at all. The ones that do usually point to the same conclusion: the server must not trust the client.

Taking over a modern Android phone takes several bugs in a row. Each link targets a different layer, and Android's design adds a defence at every one.

iOS has fewer ways in than most platforms, so attackers aim at the few that remain: messages, the browser and the kernel. Apple's defences are built around those exact paths.

Most mobile malware never breaks the sandbox. It persuades the user to hand over the permissions that let it read the screen and act as them.

Your app can be fully patched on a phone whose kernel is two years old. The answer separates what you control, what the platform controls, and what you can only measure.

Exploit chains used by mercenary spyware depend on memory corruption. Tagging every allocation and checking the tag on every access attacks that dependency directly. The answer is how it works and where it stops.

Employees will read company email on their own phones either way. The scored answer protects the data without owning the device, and is honest about what IT can and cannot see.

Spyware chains usually arrive through features most people never use. The scored answer trades those features away for the people who need it, and plans for what happens when protection is not enough.

Python sits on top of a lot of C and C++. The scored answer explains the bug class, what the mitigations do and do not stop, and where ML stacks are exposed.

The mechanism takes a minute. The score comes from saying exactly what a valid signature does not prove, and running the key-theft response.

If two independent builds from the same source produce identical bytes, a compromised build server cannot hide. The scored answer explains how, what breaks reproducibility, and why ML needs provenance instead of bit-for-bit equality.

Signed software outlives the certificate that signed it. The scored answer explains how a timestamp proves the signature was made while the certificate was valid, and how revocation dates interact with it.

Getting in once is not enough for an attacker. Persistence is where they must leave a mark on the system, which makes it one of the best places to catch them.

Breadth first, then priority. The answer that scores follows one sensitive value through every copy the system makes and fixes the two that leak most.

The attacker never sees the dataset. They see how much more confident the model is about one record than it should be.

Every model makes mistakes. An adversarial example is a mistake someone chose for it, and that changes how you measure and defend.

Language models are trained to predict text, and sometimes the best prediction is the exact text they saw. Rare, repeated and sensitive strings are the risk.

The guarantee is about what an observer can learn from your presence in the data, not about hiding the data. Epsilon bounds it; delta is the small print.

The two attacks every robustness paper starts from. The scored answer explains the gradient step, the budget as a threat model, and why the iterative attack is the standard for evaluation.

The one defence that has held up in research, at a price. The scored answer explains the min-max objective and names the costs: accuracy, compute, and robustness only to the threat model trained on.

A defence that breaks the attacker's tools is not a defence that stops the attacker. The scored answer explains how masking fools gradient attacks, how to spot it, and how adaptive attacks get around it.

Most broken defences were evaluated by their authors. The scored answer pins down the threat model, attacks the defence specifically, runs sanity checks, and reports robust accuracy with the conditions attached.

Every poisoned example looks correctly labelled to a reviewer. The scored answer explains the mechanism, why label audits miss it, and the defences that work at the pipeline level.

Three attacks that all start with queries and end with something the owner did not intend to share. The scored answer separates them by what is stolen and maps each to its defence.

Removing names removes the obvious identifier and leaves the rest. The scored answer explains re-identification, why models amplify it, and what actually bounds the risk.

DP gives a real guarantee with a real cost. The scored answer explains clipping, noise and accounting, then compares DP with cheaper controls for a concrete dataset.

A watermark is evidence of origin under conditions, not a detector of all AI text. The scored answer explains how it works, how it fails, and what claims it can support.

A research-depth question. The scored answer explains why 'was this in training' blurs at web scale, why many published attacks measured distribution shift instead, and what questions remain answerable.

Two security goals that pull against each other. The scored answer explains the mechanism, the evidence, and how to make the trade-off explicit in a design.

Generic leakage benchmarks will not tell you whether your customers' records got easier to extract. Planted canaries, matched controls and an attack-economics view of severity will.

The same model in a different context carries different obligations and harms. The scored answer names what each sector adds on top of baseline AI security.

Security asks who can steal the data. Privacy also asks what the agent itself collects, infers, remembers and passes on, about the user and about everyone in their inbox who never agreed to anything.

The first ten minutes of any design review decide its quality. This answer shows the sketch, the one question that finds most bugs, and why controls come last.

Candidates who say 'everything is new' and candidates who say 'nothing is new' both lose this one. The answer that scores names exactly three differences and keeps the rest of the toolkit.

Reciting the six letters earns little. What scores is a diagram drawn aloud, one boundary walked in depth, and a list of threats with owners.

The order lookup is the whole interview. Candidates who spend ten minutes on jailbreaks and two on authorization have it backwards.

Definitions take ten seconds. The interviewer wants a worked failure: which layer broke, which one held, and why they did not break together.

Three words people use interchangeably, and a prioritisation question that exposes whether you have ever had a backlog of thirty findings.

Neither 'block it' nor 'ship it' scores. The interviewer is watching whether you can find the one risk that matters in a day and offer a path to launch.

Five minutes, no jargon, one decision. Candidates who explain how attention works have already lost the room.