- In short
- Secure-by-design means security is designed in from the start of a build rather than bolted on after a system works. Least privilege grants each component and tool only the access it needs, and identity and access management scopes who and what can invoke sensitive capabilities.
Security as a starting point, not a finishing step
By the time you reach this knowledge point, you have seen least privilege appear again and again, as the containment layer for prompt injection, as the blast-radius control in untrusted input handling, and as a layer within guardrail layering, which is its hard prerequisite. Here, in the Guardrails and Safe Deployment task statement of the Claude Certified Developer - Foundations (CCDV-F) exam, it is promoted from a recurring tactic to a design principle. The lesson is that security is designed in from the start, not bolted on after a system works.
The apply-level skill this tests is the ability to look at how a system is being built and recognize whether security shaped the architecture or was deferred. Secure-by-design and least privilege are two sides of the same coin: the first is about when you think about security, and the second is about how much access anything is granted.
- Least privilege
- A security principle under which every component, tool, and identity is granted only the minimum access required to perform its function, and nothing more. The narrower the grant, the smaller the damage any single compromise or mistake can cause.
Least privilege, applied to every component and tool
The core rule is direct: least privilege grants each component and tool only the access it needs. Every tool an agent can call, every credential a component holds, every scope a service is granted should be the minimum that lets it do its job. An agent whose task is reading tickets gets read access to tickets and nothing else, not a broad grant that also happens to include writing, deleting, or reaching unrelated systems.
The payoff is containment, and it is the same payoff least privilege delivered in the injection knowledge points. When access is narrow, the damage from any single failure, a compromised credential, a successful injection, a buggy tool call, is bounded by how little that component could reach. When access is broad, one failure becomes a system-wide incident. This is why the first named exam trap is granting broad permissions for convenience and planning to tighten them later. The convenience is real: broad grants make development faster and avoid the friction of scoping each capability. But "tighten it later" is a promise that is rarely kept, and until it is, the system runs with an oversized blast radius. Least privilege is a starting posture, not a cleanup task.
Secure-by-design: the timing is the point
The companion principle is about sequence. Security is designed in from the start, not bolted on after a system works. The tempting order of operations is to build the system until it functions, then bring in a security review to harden it. Secure-by-design rejects that order, because by the time a system works, its architecture, its trust boundaries, and its permission model are already set, and retrofitting security into them is expensive, incomplete, and prone to leaving gaps.
This is the second named trap in its precise form: treating security as a final review step rather than a design input. A review step can catch surface issues, but it cannot easily undo an architecture that handed every component broad access or that never established trust boundaries. When security is a design input, those boundaries and those scoped permissions are decided as the system is built, so the finished system is secure by construction rather than secure by afterthought. The difference is structural, and the exam expects you to recognize it.
Identity and access management scopes the sensitive parts
The third element makes least privilege enforceable: identity and access management scopes who and what can invoke sensitive capabilities. Least privilege is a principle; IAM is the machinery that realizes it. It answers, for each sensitive capability, which identities and which components are permitted to invoke it, and it enforces that scoping rather than leaving it to convention.
For a Claude application, "who and what" is deliberately broad. It covers human users, whose permissions determine what they can ask the system to do, and it covers the non-human components and agents themselves, whose scoped credentials determine what they can reach. A sensitive capability, moving money, deleting data, accessing personal records, is gated so that only the specific identities that should invoke it can. IAM is how the abstract instruction "grant only the access needed" becomes a concrete, enforced boundary, and it is the mechanism that human-in-the-loop for sensitive actions builds on when it requires explicit approval for the highest-impact operations.
Why the two principles need each other
Secure-by-design without least privilege is a good intention with no teeth; least privilege applied only as a late cleanup is a fix that never quite arrives. Together they say: decide access early, decide it narrowly, and enforce it with identity and access management. That combination is what makes a system resilient by construction rather than by luck, and it is the design-time expression of the containment thinking that runs through all of Domain 7.
Worked example
A team is building a Claude agent to draft internal reports. To move fast, they give it a service account with full read-write access to the company data warehouse and admin rights to the reporting tool, intending to 'lock it down before launch.' Security review is scheduled for the final sprint.
Both traps are present, and they compound. The first is the broad-for-convenience grant: full read-write to the warehouse and admin rights to the reporting tool, far beyond what drafting reports requires. Drafting reports needs read access to the specific datasets a report draws on and the ability to create a draft, nothing more. The oversized grant means that any compromise of this agent, or any successful injection into content it processes, can now read or alter the entire warehouse and administer the reporting tool. The blast radius is the whole data platform.
The second trap is the timing: security is a final-sprint review rather than a design input. By the time that review happens, the agent's broad service account is woven through everything it does, and "locking it down" means untangling permissions the whole system now assumes it has. That is exactly the retrofit secure-by-design is meant to avoid. Worse, "before launch" has a way of slipping, so the system may well ship with the broad grant intact.
The secure-by-design rebuild inverts both. At design time, the team decides the agent needs read access to a defined set of report datasets and permission to create drafts, and they provision a scoped credential granting only that. IAM enforces that this identity cannot write to the warehouse or administer the reporting tool at all, because those capabilities were never in its grant. Now a compromise is contained to a handful of read-only datasets and draft creation. The security work did not slow development down at the end; it shaped the architecture at the start, which is the whole point.
Common misreadings to avoid
Misconception
We will grant the agent broad permissions now to move quickly, then tighten them before launch.
What's actually true
Misconception
Security is best handled by a dedicated review once the system is built and working.
What's actually true
How it shows up on the exam
CCDV-F questions on this knowledge point describe how a system is being built or how its permissions are granted, and ask what is wrong or which approach is sound. The credited answers name the two principles: scope every component and tool to least privilege, and design security in from the start with IAM enforcing who and what can invoke sensitive capabilities. The distractors are the two traps, broad permissions granted for convenience with a plan to tighten later, and security deferred to a final review step.
When you read one, ask two questions. Does each component hold only the access its job requires, or is it over-provisioned for convenience? And was security a design input from the start, or something bolted on after the system already worked? A design that over-grants or defers is the vulnerable option. This design-time mindset flows straight into human-in-the-loop for sensitive actions, where the most dangerous capabilities get an explicit, enforced approval gate on top of least-privilege scoping.
A developer provisions a Claude agent that only needs to summarize support tickets, but gives it an admin API key 'so we do not hit permission errors during development,' planning to reduce the scope before release. What is the best critique?
People also ask
What is the principle of least privilege?
What does secure-by-design mean?
Why not grant broad permissions and tighten them later?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.