Anthropic CCA-F: Claude Code Rules, Hooks and CI

A pull request arrives with a routine request: update an API client, run its tests and prepare a summary for reviewers. A Claude Code assistant can inspect the repository and propose the change quickly. But the same task sits at the intersection of several distinct kinds of authority. The assistant may read project instructions, invoke a shell, consult a third-party MCP server and execute inside a continuous-integration job. None of those capabilities should automatically confer permission to read production secrets or modify deployment configuration.

For architects preparing for Claude Certified Architect – Foundations, this is a useful distinction to understand deeply. Claude Code configuration is an architectural choice, not just a collection of convenient settings. The design question is how to make project guidance useful while leaving security-critical decisions with deterministic controls and accountable people.

Project instructions are helpful context, not a security perimeter

A repository often carries a CLAUDE.md file describing its architecture, test commands, naming conventions, release requirements and review style. Such instructions are valuable because they let an assistant work with the grain of a codebase. They might tell the assistant to run the unit tests for the package it changed, use a particular migration pattern or avoid altering generated files. Shared project rules can also live under .claude/rules/, including rules scoped to certain paths.

It would be a serious mistake, though, to treat a sentence in that file as access control. “Never reveal an environment variable” is an instruction the model is asked to follow. It does not itself prevent the shell from reading that variable, or a connector from receiving it. Project guidance can be missing, outdated, contradicted or intentionally manipulated in untrusted content. When the consequence matters, enforce the boundary through the tool execution environment and explicit permissions.

Consider a payments repository in which the assistant needs to update client-side validation logic. The project instructions can explain the expected validation contract, the relevant tests and the style of a pull-request summary. They should not decide whether the assistant can read customer data, rotate service credentials or merge its own work. Those decisions belong to the permissions of the identity running the tools, the repository and deployment controls, and the person or system authorized to approve the result.

This separation also helps developers keep instructions brief. Instead of filling CLAUDE.md with dozens of pseudo-security promises, document the project-specific work that actually improves decisions, and connect it to enforcement mechanisms with testable outcomes.

Scope rules, reusable skills and planning to the actual change

A project can need different guidance for different parts of a repository. Keep the top-level CLAUDE.md focused on rules that genuinely apply across the codebase, and use .claude/rules/ for narrower conventions. Anthropic documents path-scoped rules with YAML paths patterns: a payment-service rule can load when Claude examines matching payment files, while a documentation rule can govern a different subtree. These instructions organize relevant context; they do not by themselves grant, deny or enforce tool permissions.

For example, a monorepo may include a billing package, a customer-facing interface and generated API clients. The shared instructions can explain project architecture and test commands. A billing-specific rule can describe invariant currency handling, required financial test cases and the locations of policy fixtures. A separate documentation rule can ask for examples to be checked against current command output. This keeps important conventions close to the work instead of burying every instruction in a giant document that the assistant will repeatedly carry into unrelated tasks.

Reusable skills are a different tool for repeated procedures. A skill might explain how to run the billing regression suite, inspect the expected output and prepare an auditable change summary. It can make a procedure consistent across developers, including supporting scripts or templates. It is still instruction and workflow context, not a permission escalation: the executing environment must enforce which commands, files and services may be used. Even a useful skill must not inherit unrestricted production access merely because it names a release process.

Plan mode is appropriate when the scope of a change is uncertain or touches several dependent modules. Claude can inspect files, identify affected components and propose an approach before implementation. That improves the quality of the human or automated review, but an approved plan does not automatically authorize every later command. A production-impacting action still needs a valid identity, a permitted operation and whatever separate approval or hook enforcement the environment requires. In a narrow, well-understood documentation change, direct execution with suitable permissions may be simpler and sufficiently safe.

After the plan, refine iteratively. Make a small change, run focused tests, inspect the diff, compare it to the acceptance criteria and only then broaden the scope if evidence requires it. A reviewable sequence is generally more reliable than asking an agent to rewrite an entire repository and then explain what happened. For Architect Foundations, be able to distinguish four independent decisions: what instructions Claude sees, which reusable procedure helps the task, when it should plan versus execute, and what the system actually permits at execution time.

Use permissions to define what tools may actually do

Claude Code permission rules can be configured to allow, deny or ask about tool operations. The question is not simply whether the assistant can use a shell. It is which commands, files, integrations and situations warrant automatic execution, a confirmation or a refusal. A development assistant might be allowed to inspect tracked source and run a focused test suite, asked before a dependency upgrade, and denied access to sensitive local credential paths.

Define access from the task backward. A documentation cleanup needs read access, a narrow write scope and perhaps a markdown linter; it does not need deployment credentials. A dependency-security fix may require running a test command and updating the lockfile, but publishing a package or changing a cloud policy remains a separate capability. Granting broad access for convenience makes routine tasks inherit powers they cannot justify.

Permission configuration also has environmental context. A tool allowed in a developer’s disposable sandbox may not be appropriate inside a build runner with release tokens. Conversely, a deny rule applied to the wrong workspace or runner does not protect a second execution path. The owner of the workflow should inspect effective configuration, credential scope and the trust level of the files and inputs being processed. Paths, symbolic links and platform-specific behavior require testing rather than assumptions.

A useful review records three things for each consequential operation: who or what initiates it, which mechanism can approve or reject it, and what audit evidence remains. That turns “the assistant is safe” into a set of concrete controls that can be checked after an incident.

Hooks protect selected actions at the point of use

Hooks respond to defined Claude Code lifecycle events. A PreToolUse hook can examine a proposed tool operation before the tool runs and, when properly configured, block it. This is qualitatively different from asking the model in a prompt not to do something. The hook is evaluated in the workflow that processes the tool call, rather than relying solely on the model to remember an instruction. Anthropic’s documentation describes decisions such as allow, deny and ask, along with ways to inspect the intended tool and its inputs.

Suppose an assistant can run tests but should never issue a deployment command from a feature-branch session. A pre-execution check can reject an attempted deployment operation. Another hook might add a verification step after a file edit, while an audit hook records which test command ran. The critical design detail is to understand exactly which event each hook sees and what outcome it can guarantee. A hook invoked only for tool calls cannot prevent a wholly separate process from reading the same files; a check implemented only for Bash does not automatically cover every other tool that can modify a resource.

Hooks also introduce failure modes of their own. A script may crash, time out, parse a command poorly or make a decision with incomplete context. A policy that depends on a hook should specify what happens when the check cannot return a valid decision, and should test representative bypass attempts. Treat a successful demonstration as evidence for the case tested, not proof that every possible action path is guarded.

The strongest architecture uses complementary controls: narrow runner credentials, permission rules, hooks for selected execution checks, protected branches, ordinary build tests and human review for sensitive changes. These controls are not interchangeable. A hook that refuses a command does not replace branch protection; an approval workflow does not make tool output trustworthy.

Keep MCP tool access separate from project context

Model Context Protocol helps clients discover tools, resources and prompts supplied by external integrations. That standardizes an interface; it does not confer the trustworthiness of an integration or the authority to act on whatever it returns. A coding assistant might receive an issue description from an MCP resource and use it as evidence about what to fix. The issue description is not a new instruction granting permission to export a repository, alter access controls or send data to another server.

For an architecture review, trace a particular tool call end to end. Which identity does the server see? Is the request tied to a specific repository and user? Does the endpoint return sensitive fields the assistant does not need? Can the server perform writes, or only read? What happens if its response includes malicious text posing as a higher-priority instruction? A secure design answers these questions in the connector, application and approval layer—not merely in a reassuring sentence about responsible AI.

The same principle applies to delegated subagents. Giving a specialist assistant only the tools relevant to its task can reduce ambiguity and exposure. But a subagent receiving a summary of another agent’s findings still needs to know which parts are observed facts, which are untrusted content and which decisions require fresh authorization. A delegated role is not an escalation of privilege by itself.

The Developer Foundations discussion of tools, agents and MCP goes deeper into the integration mechanics. The Architect Foundations decision is where that mechanism belongs in the system and how its permissions intersect with the workflow around it.

Design CI workflows around narrow identities and observable evidence

Continuous integration exposes a particularly important trap: the assistant may be introduced to help review code but executed in an environment that can publish releases. Those are different responsibilities. A pull-request job should normally receive the least powerful identity sufficient to fetch code, run the necessary checks and report findings. A privileged deploy job should be a separate, controlled path. Store tokens in the platform’s secret facility, scope them to the required operation and avoid exposing them to untrusted pull-request content.

Take a repository where contributors can submit changes from external forks. If a CI job blindly checks out the contributor’s code and then runs it with broad write tokens, the attacker controls the material being executed in a privileged environment. Adding a Claude agent to summarize changes does not solve this underlying trust-boundary problem. Separate untrusted builds from privileged steps; review the platform’s token and event permissions; and ensure no automated summary is interpreted as authorization to release.

What should the assistant itself do? In many workflows it should analyze diffs, propose tests, summarize suspected failures and post findings for a reviewer. Whether it should automatically write a commit depends on the repository’s change policy and permissions. Whether it may merge, publish or deploy is another decision again. A tool that can suggest a release note should not thereby obtain production deployment rights.

Failure handling must be explicit. If a CI job times out during a package-publishing step, rerunning it blindly may duplicate an action or produce an inconsistent release. A robust pipeline checks the external system’s resulting state and uses idempotent operations where possible. Similarly, if Claude reports an uncertain tool execution, the application should verify the side effect rather than assume the request either succeeded or failed. The Architect Professional treatment of tool boundaries provides a wider enterprise perspective on this distinction.

Evaluate the controls with adversarial, ordinary and interrupted workflows

A security review should not stop at “we installed a hook” or “we wrote a deny rule.” It needs a small, representative set of experiments in a nonproduction environment, with the expected result defined before the run. The cases should include ordinary work, deliberately unauthorized work, hostile external content and partial failures. This does not mean inventing an unsafe exploit chain; it means proving the stated boundary for realistic workflows.

The test should include the failure of the very control it is meant to exercise. If a hook process crashes, does the action proceed, stop or request approval in the exact environment being deployed? If permission rules are changed in a branch, does the runner use a trusted configuration or the branch’s proposed one? These details decide whether the policy is operational, not merely documented.

Measurements should cover correct task completion as well as security. Excessive prompts can frustrate teams and encourage users to seek shortcuts, while permissions so broad that nothing is reviewed leave little accountability. The design target is a predictable escalation path where the normal work succeeds and significant deviations receive the attention they merit.

What Architect Foundations scenarios are really asking

A scenario may describe a team using Claude Code to maintain a service, a new MCP integration that reads customer information or a CI job that executes assistant-generated changes. Strong answers begin by identifying the asset, the proposed action and the trust boundary. Then ask which part needs flexible judgment and which part must be deterministic. Reading source to propose a fix and independently deciding to deploy that fix are separate acts. Retrieving an issue and obeying instructions embedded inside it are also separate acts.

A useful practice method is to compare two plausible designs, not simply label one “secure.” One may route every tool request to a manual approver; another may grant tightly scoped read operations automatically while reserving approval for write or export operations. Which is stronger depends on the task, identity, operational cost and consequence of an error. The correct reasoning is about proportional control, not maximum friction.

Likewise, an architecture based entirely on long project instructions is weaker for an enforceable policy than an architecture with permissions and targeted hooks, but the latter still needs correct deployment and verification. A hook is one layer among many. In the official blueprint, Claude Code configuration and workflows sit alongside agentic architecture, tool design, structured output and context reliability. Candidates must see how a change in one layer affects the others.

For readers comparing credential depth, the Claude Developer Foundations credential reflects the implementer’s view of tool and API behavior, while Architect Foundations focuses on designing the system’s boundaries. The difference becomes most visible when a technically working integration is still unacceptable because its permissions, retry behavior or audit trail are wrong.

The practical takeaway is to design a small, demonstrable set of trustworthy operations and then widen access only when evidence supports it. Good Claude Code architecture is neither an enormous instruction file nor a blanket permission switch. It is a system where project context helps the assistant do useful work, and the surrounding controls determine what work it is actually allowed to do.