DEV Community: Momin Aziz

Government of Canada IT Jobs in Ottawa

Momin Aziz — Wed, 04 Nov 2026 12:11:46 +0000

Originally published on the CVFit blog.

I'm Momin, founder of CVFit in Ottawa. I build a tool that tailors a resume to a specific job using only work you have actually done. Federal hiring runs on acronyms — IT-02, CS-2, the "Software Solutions" stream, GC Jobs, FSWEP — and this is the plain-language version: what the levels mean, what they currently pay, who's eligible, and how the screening and security process works, with links to the official pages for everything that matters.

Full disclosure: this is my product area. The facts below come from the Government of Canada's digital careers page, the TBS–PIPSC collective agreement, and the Public Service Commission.

CVFit is independent. We're not affiliated with the Government of Canada, the Public Service Commission or the Treasury Board of Canada Secretariat (TBS).

What counts as a Government of Canada IT job

Most federal technology roles sit in the Information Technology (IT) group — one of the classification groups the Treasury Board bargains pay and conditions for. If a posting's classification code starts with "IT," it belongs to this group, regardless of which department is hiring. Ottawa-Gatineau has the largest concentration of these roles because it's where most federal headquarters functions sit, but IT-group jobs exist in offices across the country.

Some separate agencies, such as the Canada Revenue Agency, use their own classification and pay plans instead of the core IT group, so don't assume every federal tech job uses IT-0X titles. When a posting names a different pay group, check that agency's own careers page rather than applying the IT group's numbers to it.

IT-01 to IT-05: what each level actually does

The Government of Canada's digital careers page breaks the IT group into five levels:

IT-01 (Technicians): provide technical support in the development, implementation, integration and maintenance of service delivery. IT-01 roles are mainly in the Infrastructure Operations, Security and Software Solutions streams.
IT-02 (Analysts): provide technical services, advice, analysis and research in their field of expertise. For pay, streams and how to qualify at this level, see our IT-02 jobs guide.
IT-03 (Team Leads / Technical Advisors): splits into two tracks — a supervisory track leading a team, and an individual-contributor track giving specialized technical advice without managing people.
IT-04 (Managers / Senior Advisors): oversees service delivery (management track) or provides expert strategic direction (senior advisor track).
IT-05 (Directors): directs and plans IT services or operations through subordinate managers.

If you're early in your career, IT-01 and IT-02 are the realistic targets. IT-03 is where "do I manage people or stay technical" becomes a real fork.

Current IT pay, by level

Pay rates for the IT group come from Appendix A of the agreement between the Treasury Board and the Professional Institute of the Public Service of Canada (PIPSC), group code 303. As of November 3, 2026, the latest published rates are the ones effective December 22, 2024 (the final scheduled increase under the agreement that expired December 21, 2025). The annual ranges (minimum to maximum step) are:

Level	Minimum	Maximum
IT-01	$69,361	$89,382
IT-02	$85,854	$105,080
IT-03	$101,343	$125,914
IT-04	$116,037	$144,434
IT-05	$133,582	$174,076

A few things worth knowing before you treat these as fixed:

These are core public administration rates. Separate agencies and Crown corporations can pay differently for similar-sounding work — check the specific employer's own pay page.
Where you land in the range depends on step, which usually increases with time in the role, not just experience before you joined.
Bargaining for a new agreement is underway. Treasury Board's collective bargaining update lists the IT group as in progress, so these numbers may change. Check the current IT group agreement page for the live numbers before you negotiate or set expectations.

The eight IT work streams

Within the IT group, most work is organized into eight standardized streams. A posting's stream tells you more about day-to-day duties than the level number does:

IT Business Line Advisory Services
IT Database Management
IT Enterprise Architecture
IT Infrastructure Operations
IT Planning and Reporting
IT Project Portfolio Management
IT Security
IT Software Solutions

If you're a developer, "Software Solutions" is usually the match. If you're closer to networking or systems administration, look at "Infrastructure Operations." Security-specific roles (not just security-cleared roles — actual cybersecurity work) sit in "IT Security."

Who can apply

You don't need to be a Canadian citizen to apply. But Government of Canada jobs advertised externally use an order of preference, as the Public Service Commission (PSC) explains:

Eligible veterans get first preference — someone honourably released from the Canadian Armed Forces after at least three years of service, released within the last five years, and not already holding an indeterminate position in the core public service or a separate agency.
Canadian citizens and permanent residents get second preference.
Other candidates get third preference.

Preference only kicks in among candidates who already meet every essential qualification — it doesn't replace merit, and it's applied "at the time of each appointment," so your status at the moment you'd actually be appointed is what counts, not your status when you applied.

Language requirements

Positions require English, French, or both (bilingual), and the hiring manager decides which. For bilingual roles, the PSC's language requirements page explains the system: reading, writing and oral interaction are each set at A (beginner), B (intermediate) or C (advanced), and some specialized positions use a "P" code. A profile like "CBC/CBC" tells you the level required in each skill.

The distinction that actually matters for applicants:

Imperative appointment: you must already meet the language levels at the time of appointment.
Non-imperative appointment: you can be appointed if you agree to reach the required level through language training at government expense.

Check which basis a posting uses before assuming a bilingual requirement rules you out.

Security screening

Every federal job needs a valid security status or clearance — it's a condition of employment. Per the Government of Canada's security screening overview, there are three standard levels, each with an enhanced option:

Reliability Status
Secret
Top Secret

All levels include identity and background verification, a criminal record check, and a financial inquiry (credit check). Higher levels add security interviews or questionnaires, internet checks, law-enforcement record checks, and — at the highest level — polygraph examinations.

Processing time varies: anywhere from "a few days to several months," depending on the level and other factors. Don't assume a slow screening means you were rejected. The same page notes that only a small fraction of applicants are denied.

Where to find Government of Canada IT jobs in Ottawa

GC Jobs — the official search for Government of Canada jobs, including IT postings across departments.
The Government of Canada jobs hub — a broader entry point if you're not sure which search tool you need.
Agencies' own career sites — if you're targeting a specific separate agency or Crown corporation, check its careers page as well as GC Jobs.
Tech jobs in Ottawa on CVFit, for the private-sector side of the same city (or tech jobs across Canada) — useful context if you're deciding between a federal and a private-sector offer, or widening your search while you wait out a federal process. Our guide to tech jobs in Ottawa covers who's hiring locally.

How the application actually works

The PSC's own overview of what to expect lays out five steps, not necessarily in this order: submit your application, get screened, complete a written test or interview if you're screened in, provide references and pass security screening, then get a status update through your GC Jobs account or by email.

Two things to plan around:

Many postings create a "pool." A single ad can be used to hire for more than one position over time, including positions that don't exist yet when you apply. Check the "Intent of the Process" section on the poster — if it mentions a pool, a slow response doesn't mean you were screened out; it can mean you're in the pool for a future opening.
The process is slow by private-sector standards. The PSC says the median time to hire a new candidate was 227 days in 2021, with each step taking anywhere from four weeks to a few months. Apply to pools and treat the process as a long game, not a two-week turnaround.

Tailoring your résumé to essential qualifications

Federal screening doesn't work like most private-sector applicant tracking. A GC poster lists essential qualifications — education, experience, sometimes specific competencies — and your written application needs to prove each one with a concrete example, not just a claim. Many posters spell this out: it isn't enough to say you have a qualification or list your responsibilities; you need to explain the "what, when, where and how." The PSC's how-to-apply guide says the same: give details or examples, use the exact keywords from the question, and if a question says "and," show every part.

For every experience-based qualification, aim to answer:

Where you gained it — the organization.
What role and when — title, level, and dates (month and year).
What you actually did — a specific task or project, ideally as a short situation–task–action–result.

To work through a poster qualification by qualification, you can tailor your CV to the job description in CVFit. If you're facing a screening-questions round and want the step-by-step on answering those with STAR, see our guide to answering Government of Canada screening questions.

Student and early-career routes

You don't need prior federal experience to start. The main entry programs, per the digital careers page and the Federal Student Work Experience Program (FSWEP):

FSWEP — for full-time secondary or post-secondary students who meet the minimum age in their province or territory and are returning to full-time studies (or, in their final year, have worked under FSWEP, Co-op/Internship or the Research Affiliate Program before). It's an inventory: you apply once, and managers pull matching applications through the year. The main student inventory is open year-round to over 200 departments and agencies.
Post-Secondary Co-op/Internship Program
Research Affiliate Program
Information Technology Apprenticeship Program (ITAP)
A dedicated recruitment initiative for digital careers for persons with disabilities.

In FSWEP, as in general hiring, preference goes to Canadian citizens and permanent residents who meet the job requirements.

FAQ

What's the difference between IT-01 and IT-02? IT-01 is a technician-level role focused on technical support for developing, implementing and maintaining service delivery. IT-02 is an analyst-level role that adds advice, analysis and research in a specific area. Check the level on each poster rather than assuming a job title maps to one level. For a deeper breakdown of IT-02 pay, streams and how to qualify, see our IT-02 jobs guide.

Do I need to be a Canadian citizen to apply? No. Anyone can apply, but veterans, then citizens and permanent residents, get preference among qualified candidates.

Do I need to be bilingual to get a federal IT job? Not always. Only positions designated bilingual need both languages. Where a bilingual position is staffed "non-imperatively," you can be hired while you work toward the required level through government-paid training.

How long does it actually take to hear back? In 2021, the PSC reported a median of 227 days to hire a new candidate, with wide variation by step. A pooled posting can mean a slow response simply reflects pool status, not rejection.

Does CVFit have Government of Canada job listings? No — CVFit's job index covers private-sector postings, including tech jobs in Ottawa. For federal postings, use GC Jobs directly. What CVFit can help with is turning your résumé into evidence for each essential qualification once you've found a posting: paste the posting and your CV into our match tool to see your match score and a quote-backed look at what's covered and what's missing, or use tailor your CV to a job description to work through each qualification in detail. One month of Pro is free, no credit card required.

Paste a Government of Canada posting and your résumé into CVFit to see your match score and gaps against the essential qualifications. Every match is backed by a quote from your CV. Check your match now → — 1 month of Pro free, no credit card.

Read the original post on CVFit: Government of Canada IT Jobs in Ottawa

Try the free match checker — paste a job description and see how your resume lines up, with no account needed for a first check.

Tech Jobs in Ottawa: Who's Hiring

Momin Aziz — Wed, 04 Nov 2026 12:09:29 +0000

Originally published on the CVFit blog.

I'm Momin, founder of CVFit in Ottawa. I build a tool that tailors a resume to a specific job using only work you have actually done — and I run a live index of tech jobs across the city. This is the city-specific version of "tech jobs Ottawa": where the jobs are, who's posting right now, how the public/private split works here, what security clearance means for a civilian applicant, and what changed in job postings as of January 2026.

CVFit is independent. We're not affiliated with Invest Ottawa, the Kanata North Business Association or any employer named below.

Ottawa's tech market, in one paragraph

Ottawa is a federal government town first, and that shapes its private tech sector: some local companies sell into government and defence contracts, and plenty of engineers weigh public-service and private-sector jobs side by side. The other defining feature is geography — a big share of the city's tech employers sit in one place, Kanata North, which its business association calls Canada's largest technology park.

Kanata North and the rest of the city

Kanata North is the single biggest concentration of tech employers in the city. Per the Kanata North Business Association, the park has 540+ companies and 33,000 employees, and contributes more than $13 billion a year to Canada's GDP. The association's strategic plan highlights recent investments by Nokia (including a cybersecurity R&D campus), Ericsson, Wind River and Dell, and member companies in emerging sectors like clean tech, AI, fintech and healthcare.

Outside Kanata, tech employers are spread across downtown and the rest of the city, and some Ottawa-listed roles are remote. Check the location line on each posting before you plan a commute.

Who's hiring: tech jobs in Ottawa right now

A snapshot, not a ranking: in November 2026, employers posting on CVFit's Ottawa page included:

Broadcom — staff and principal hardware and software engineering roles on March Road
Solace — from a Junior Software Developer role up to Principal Software Developer
Pleora Technologies — Software Developer
Solink — including a Software Engineer Co-op
Ranovus — optical and verification engineering
MindBridge AI — data science, data engineering and QA automation
Corsa Security, Intouch Insight, RBR and Assent Compliance — sales, software, QA and other roles

That list changes daily as postings open and close, so check the live page for what's open today.

Public sector vs. private sector

Ottawa is one of the few Canadian cities where "government job" and "tech job" genuinely overlap. If you're weighing both paths:

Public sector (federal IT): Government of Canada IT roles use the IT-01 through IT-05 classification system, with a defined process involving GC Jobs, screening against essential qualifications, and often a long timeline. We cover this in detail in our guide to Government of Canada IT jobs in Ottawa — including current pay by level and how the application process works.
Private sector: Faster-moving hiring, and more variation in process and pay by company.

Nothing stops you from applying to both at once — and given how long federal hiring can take, many people do.

Security clearance and controlled goods

Because some of Ottawa's private tech sector works on government and defence contracts, you'll see security requirements in some private-sector postings too, not just federal ones.

Two distinct things get bundled together under "clearance," and postings aren't always precise about which one they mean:

Government security screening (Reliability Status, Secret, Top Secret) — required for federal roles and for private-sector roles supporting certain federal contracts. Covered in detail in our Government of Canada IT jobs guide.
Controlled Goods Program (CGP) security assessment — a separate requirement run by Public Services and Procurement Canada. Companies that examine, possess or transfer "controlled goods" (certain defence-related goods and technology) must register, and their employees — including temporary workers and international students — must be security-assessed, usually by the company's designated official, before they can access those goods. An approved assessment is valid for up to five years while you stay with the same organization; it doesn't transfer to a new employer.

If a posting mentions either requirement and you're unsure whether you'd qualify, ask the employer early rather than assuming your application was simply ignored.

Pay transparency in Ontario postings (2026)

As of January 1, 2026, Ontario employers with 25 or more employees have new rules for publicly advertised job postings, including the ones you'll see for Ottawa tech roles. Per Ontario's Employment Standards Act guide, postings must include:

The expected pay, or a pay range — and the range can't span more than $50,000 a year (this doesn't apply once the pay, or the top of the range, is above $200,000 a year).
Whether artificial intelligence is used to screen, assess or select applicants.
Whether the posting is for an existing vacancy or not.

Postings also can't require Canadian experience, and if you're interviewed, the employer has to tell you within 45 days whether a hiring decision has been made.

None of this obligates an employer to pay within the posted range — it governs what has to appear in the ad, not what you'll be offered. But it does mean postings from employers with 25+ staff for Ontario-based roles should now show a real number, which is useful when you're deciding which roles are worth your time.

Where to search for tech jobs in Ottawa

CVFit's live Ottawa index — 500+ tech roles sourced from employer job boards and regional tech networks, updated daily. Filter by keyword or use the natural-language job search. For other cities, see tech jobs across Canada.
Invest Ottawa's Tech Job Finder — openings across the Invest Ottawa network.
Discover Technata's job board — openings across the Discover Technata network, another Ottawa-focused board worth checking alongside the national sites.
Company career pages directly, especially for the larger Kanata North employers — some openings may only appear there.

How to get noticed

Ottawa tech postings, especially in telecom and defence-adjacent companies, often list specific technical requirements in dense, acronym-heavy language. Mirror the posting's own wording rather than paraphrasing it — if the posting says "RF" or names a specific protocol, use that exact term, not a general synonym. Some employers also use software to screen applications; under the new Ontario rules, the posting has to tell you if AI is used.

If you want help checking whether your résumé covers what a specific posting asks for, paste both into CVFit's match tool — it shows your match score and the top missing requirements, with every match backed by a quote from your own CV. To rework your CV for one role, tailor your CV to the job description.

Early-career routes

If you're newer to the market, Ottawa has routes into tech that don't require years of private-sector experience first:

Federal co-op and student programs (FSWEP, Post-Secondary Co-op/Internship, the IT Apprenticeship Program) — covered in our Government of Canada IT jobs guide.
Private-sector co-op, junior and technician roles — on November 3, 2026, for example, our Ottawa page listed a Software Engineer Co-op at Solink and a Junior Software Developer role at Solace.

FAQ

Is Ottawa a good city for tech jobs outside of government? Yes — Kanata North alone has 540+ companies and 33,000 employees, per its business association, with big names like Nokia and Ericsson and newer firms in AI, fintech and clean tech. It's a smaller market than Toronto or Vancouver, but it's dense rather than thin.

Do I need a security clearance to work in Ottawa tech? Only for specific roles — typically ones supporting federal or defence work. Government security screening (Reliability Status, Secret, Top Secret) and a Controlled Goods Program security assessment are two separate requirements that sometimes both apply. Many private-sector roles need neither; check the posting.

What changed in Ottawa job postings in 2026? As of January 1, 2026, Ontario employers with 25+ employees must show expected pay or a range (no wider than $50,000, with an exception above $200,000), say whether AI is used in screening and whether the job is an existing vacancy, drop Canadian-experience requirements, and tell interviewed applicants within 45 days whether a hiring decision was made.

Does CVFit have a list of Ottawa employers? CVFit indexes live postings at /jobs/canada/ottawa rather than keeping a static employer directory — the list changes as postings open and close. For other cities, browse tech jobs across Canada.

Browse live tech jobs in Ottawa, then paste a posting and your CV into CVFit to see your match score and gaps — every match is backed by a quote from your résumé. 1 month of Pro free, no credit card.

Read the original post on CVFit: Tech Jobs in Ottawa: Who's Hiring

Try the free match checker — paste a job description and see how your resume lines up, with no account needed for a first check.

IT-02 Jobs: Pay and How to Qualify

Momin Aziz — Wed, 04 Nov 2026 11:52:58 +0000

Originally published on the CVFit blog.

I'm Momin, founder of CVFit in Ottawa. I build a tool that tailors a resume to a specific job using only work you have actually done. Federal IT hiring is where that rule matters most — posters are precise about what counts as proof.

Full disclosure: this is my product area. The facts below come from the Government of Canada's digital careers page, the TBS–PIPSC collective agreement, and real IT-02 posters.

CVFit is independent. We're not affiliated with the Government of Canada, the Public Service Commission or the Treasury Board of Canada Secretariat (TBS).

What IT-02 means

On the Government of Canada's digital careers page, IT-02 is the analyst level. Analysts "provide technical services, advice, analysis, and research in their field of expertise to support service delivery to clients and stakeholders." Unlike IT-01 technicians, who are mainly found in three streams, IT analysts appear in all eight IT work streams.

A few naming notes that trip people up:

IT-02 replaced CS-02. The old Computer Systems (CS) group was renamed Information Technology (IT). Pay mapping stayed the same — a CS-02 rate maps to IT-02 — even though you'll still see CS language on older documents and some third-party job boards.
The job title on the poster is not the classification. You might see "IT Analyst, Software Solutions," "IT Analyst, Infrastructure Operations," or a department-specific title. The classification code (IT-02) is what sets the pay band and the level of work expected.
Analyst does not mean "junior by default." IT-02 is the main working level for many federal developers, administrators and specialists. IT-01 is the more common true entry point; IT-03 is where team-lead and senior-advisor tracks split.

IT-02 pay

Pay for the IT group comes from Appendix A of the agreement between the Treasury Board and the Professional Institute of the Public Service of Canada (PIPSC), group code 303. As of November 3, 2026, the latest published rates are the ones effective December 22, 2024 (the final scheduled increase under the agreement that expired December 21, 2025).

Level	Minimum	Maximum
IT-01	$69,361	$89,382
IT-02	$85,854	$105,080
IT-03	$101,343	$125,914

What that means in practice:

IT-02 sits between technician and team-lead / technical-advisor pay. Moving from the top of IT-01 into IT-02 is a real step up; moving from the top of IT-02 into IT-03 is another.
Where you land in the range is usually a step, which advances with time in the level (the agreement sets a twelve-month increment period for IT-01 through IT-05), not only with prior outside experience.
These are core public administration rates. Separate agencies and Crown corporations can use different pay plans for similar-sounding work — always check that employer's own page.
Bargaining for a new agreement is underway, so confirm the live numbers on the IT group agreement page before you set expectations.

IT-02 vs IT-01 vs IT-03

Using the official role summaries on the digital careers page:

	IT-01 (Technician)	IT-02 (Analyst)	IT-03 (Team Lead / Technical Advisor)
Focus	Technical support for developing, implementing, integrating and maintaining service delivery	Technical services, advice, analysis and research in a field of expertise	Either supervising a team, or giving specialized technical advice without managing people
Streams	Mainly Infrastructure Operations, Security, Software Solutions	All eight streams	All eight streams
Typical fork	Common early-career / support entry	Main individual-contributor working level for many specialties	"Do I manage people, or stay deep technical?"

The practical test when you read a poster: does the work stop at delivering and supporting a solution, or does it expect you to advise, analyze and research as part of the job? If the poster reads like ownership of analysis and recommendations — not only ticket work or tightly scripted build tasks — you're usually looking at IT-02 or above. If it also expects you to supervise people or act as the specialized advisor for other teams, look at IT-03.

What IT-02 work looks like by stream

The digital careers page lists eight standardized streams. The stream descriptions below are the official responsibilities for that work — an IT-02 in that stream is the analyst doing that work at the "services, advice, analysis and research" level:

IT Business Line Advisory Services — specialized IT guidance; working with clients or suppliers so IT resources support business objectives (business analysis, client portfolio management, supplier relationship management and related functions).
IT Database Management — data models and databases: design, capacity planning, performance and tuning, security and recovery.
IT Enterprise Architecture — departmental IT architecture direction; research into emerging technologies; helping define the future state of IT against business needs.
IT Infrastructure Operations — networks, mainframes, servers, storage; help-desk support; in smaller organizations, also the client and supplier interface.
IT Planning and Reporting — IT planning guidance; strategic plans, policies, standards and governance processes aligned with business objectives.
IT Project Portfolio Management — full-time work on large formal projects or portfolios that need rigorous IT project management; project management services for major IT initiatives.
IT Security — availability, integrity and confidentiality of infrastructure, applications and data; security applications, strategies, policies, processes and risk frameworks.
IT Software Solutions — developing and maintaining custom, proprietary or commercial applications; systems design and development, business analysis, programming, configuration, testing and implementation.

If you're a developer searching "IT-02 jobs," Software Solutions is usually the match. If your background is networking, endpoints or platforms, start with Infrastructure Operations. Security-cleared work is not the same as the IT Security stream — the stream is for people whose job is security work itself.

Education and experience on real IT-02 posters

Education (the group minimum)

The minimum education standard for the IT group, on both the digital careers page and the TBS qualification standards, is:

Graduation from a two-year program of study from a recognized post-secondary institution with acceptable specialization in computer science, information technology, information management or another specialty relevant to the position to be staffed.

Posters usually repeat that wording, then add grandfathering notes for long-serving IT/CS incumbents, and often a manager's discretion note: an acceptable combination of education, training and/or experience may replace the credential for that specific position only, and must be reassessed for other jobs.

Experience (what changes from poster to poster)

Experience criteria are where IT-02 posters diverge. Two patterns show up often:

1. Stream-specific skills, sometimes without a "years" definition.

A 2025 Department of National Defence inventory for IT Analyst, IT Software Solutions (IT-02; pay listed as $85,854 to $105,080; closing 16 December 2025 on the regional posters) asked candidates to show, among other things:

experience developing software solutions on technology platforms (examples named included C#, React, Oracle Apex, or other platforms as applicable)
experience with system development life cycles (examples named included Waterfall, V-Model, iterative)

Those experience lines were essential at application. Competencies and the ability to analyze and document technical problems were flagged for assessment later. The same inventory also required Secret security clearance as a condition of employment.

2. "Significant" and "recent" experience, with the poster defining both.

An RCMP IT Analyst (IT-02) inventory (poster 2286769; closing 12 August 2025; pay listed as $85,854 to $105,080) used definitions like:

Recent — experience normally acquired within the last five years (that poster's definition)
Significant — depth and breadth normally associated with performing the duties continuously for about two years (that poster's definition)

and asked for recent or significant experience across infrastructure delivery, technical documentation, endpoint/peripheral support, analysis and design from requirements, and technical research. Other posters define the same words differently — for example, "significant" as three or more years, or "recent" as within the last two. Always use the definitions on the poster in front of you, not a generic industry meaning.

Two application habits that matter at IT-02 as much as at any other level, from the PSC's how-to-apply guidance and Treasury Board's understanding-the-application-process page:

Prove each essential experience line with what, when, where and how — not a yes/no or a paste of your job description.
Prefer the poster's exact keywords over synonyms.

How to show IT-02-level experience on a résumé

Federal screening wants evidence at the analyst level: you didn't only execute a ticket — you analyzed, advised or researched inside your stream. A practical way to rewrite a bullet:

Before (too thin for an IT-02 experience screen):

Developed web applications and worked with databases.

After (illustrative — not a real candidate):

From March 2023 to Present, as a Software Developer at Example Org, designed and implemented REST features in C# for an internal case-management app used by 40 staff; wrote the technical design notes from business requirements, pair-reviewed pull requests, and reduced a weekly reporting query from ~90 seconds to under 10 seconds by changing the SQL and indexing.

That second version gives the screening board the organization, title, dates, the analyst-shaped work (design from requirements, not only coding), and a concrete result — the same three beats Treasury Board asks for on experience criteria.

If you're working through a live poster, paste it into CVFit's match tool to see which essential lines already have quote-backed evidence on your CV and which still need a stronger example. For the screening-question write-up itself (STAR, "I" not "we," AI rules on the poster), see our guide to answering Government of Canada screening questions.

FAQ

Is IT-02 the same as CS-02?

For pay and level, yes — CS-02 mapped to IT-02 when the occupational group was renamed. Use the classification on the current poster.

Is IT-02 entry level?

Often no. IT-01 is the more common technician / early entry level. IT-02 is the main analyst working level across streams. Some people do enter at IT-02 with enough outside experience; the poster decides.

What does an IT-02 make?

Under the latest published TBS/PIPSC rates (effective December 22, 2024), the IT-02 annual range is $85,854 to $105,080 in the core public administration. Confirm on the current agreement page, because bargaining may change the numbers.

IT-02 vs IT-03 — how do I choose which posters to apply to?

If the work is hands-on analysis and delivery in your specialty, start with IT-02. If the poster expects you to supervise a team or act as the specialized technical advisor for others, look at IT-03. Applying to both is common when your experience sits near the boundary — just tailor each application to that poster's essential qualifications.

Does CVFit list IT-02 openings?

No. Federal IT-02 roles are posted on GC Jobs. CVFit indexes private-sector tech jobs in Ottawa and can help you check your résumé against a poster's essential qualifications once you've found one.

Paste an IT-02 posting and your résumé into CVFit to see your match score and gaps against the essential qualifications. Every match is backed by a quote from your CV. Check your match now → — 1 month of Pro free, no credit card.

Read the original post on CVFit: IT-02 Jobs: Pay and How to Qualify

Try the free match checker — paste a job description and see how your resume lines up, with no account needed for a first check.

Antigravity and Codex security: stopping secret leaks with hooks and sandboxes

Momin Aziz — Sun, 01 Nov 2026 13:13:40 +0000

Originally published at ReclaimLLM.

How Google Antigravity and OpenAI Codex agents read, print, and send secrets; what hooks and sandboxes cover; and where vendor docs leave failure modes undocumented.

Antigravity and Codex security: stopping secret leaks with hooks and sandboxes

Executive summary

Side-by-side of Antigravity and Codex: where secrets leak, what each vendor’s hooks/sandbox cover, and fail-open/fail-closed behavior.
Antigravity App sandboxes terminal commands on by default; CLI (agy) defaults sandbox off (auto-enables in auto mode). Google’s hook crash/timeout fail mode is undocumented.
Codex sandbox modes: read-only, workspace-write (default), danger-full-access; approvals on-request / never.
ReclaimLLM ships Antigravity hooks with env DLP and egress guard (not capture-only). AD-015, the automated egress-anomaly detector, does not yet cover Antigravity.

Google Antigravity and OpenAI Codex both offer hooks that can deny a tool call before it runs, plus sandboxes or approval boundaries that limit what shell commands can do. Neither stack gives you secret protection by default: post-tool hooks cannot undo side effects, and hook failures do not always block the underlying action. For a team rolling out either agent in 2026, the practical answer is to combine pre-tool hooks, network limits, env-file controls, and session capture you can review after the fact.

This guide compares Antigravity and Codex side by side: where secrets leak, what each vendor documents, and how ReclaimLLM extends both with shipped hooks, env DLP, and an egress guard. Facts about vendor behavior were checked against public documentation in October 2026; re-verify Antigravity docs before you change production policy—they change often.

Three ways coding agents leak secrets (read, print, send)

Every coding agent faces the same three exfiltration paths, whether the model runs in the cloud or on your laptop:

Read — the agent opens .env, key files, or config that holds credentials.
Print — shell output, logs, or MCP responses echo secrets into the transcript.
Send — HTTP, browser navigation, or copy-to-clipboard moves data off the machine.

For a vendor-neutral map of those paths and the control layers that address them, see What is AI DLP?. The sections below focus on Antigravity and Codex specifically.

Antigravity security

Gemini CLI → Antigravity CLI (`agy`)

On June 18, 2026, Google announced that Gemini CLI and Gemini Code Assist IDE extensions would stop serving Google AI Pro/Ultra and free individual users. Gemini Code Assist Standard/Enterprise and paid API-key users can keep using Gemini CLI. For everyone else, Antigravity CLI (agy) is the replacement path.

Timeline note: Antigravity as an IDE existed before that cutover. Research such as PromptArmor’s exfiltration write-up and Simon Willison’s commentary (25 November 2025) predates the June 2026 consumer CLI transition—they describe Antigravity-era behavior, not the later Gemini CLI → agy migration by itself.

Hooks

Antigravity loads hooks from project .agents/hooks.json and user ~/.gemini/config/hooks.json. Documented events include SessionStart, PreToolUse, PostToolUse, PreInvocation, PostInvocation, and Stop.

On PreToolUse, decisions include allow, auto_approve, deny, ask, force_ask, and deny_unless_prior_grant, and hooks can overwrite tool input before execution. See Antigravity hooks.

PostToolUse does not receive tool output in the documented hook payload—only an error field when something failed—so post-tool hooks cannot redact what already ran. Prevention has to happen at PreToolUse or in sandbox/network policy.

Hook failure behavior: As of our October 2026 doc review, Google does not document whether Antigravity’s hook runner fails open or closed on crash, timeout, or malformed hook output. Do not assume either behavior; treat undocumented failure modes as a gap in your risk register.

Terminal sandbox

Sandbox defaults depend on surface, not account type:

Surface	Default sandbox behavior
Antigravity App	Terminal sandbox on by default
Antigravity CLI (`agy`)	`enableTerminalSandbox` defaults to false; auto mode can enable it

Sandboxed commands get no network access by default; domains allowed under read_url are added to the sandbox outbound allowlist. Business and enterprise accounts use a different escape-hatch syntax (unsandboxed(...) vs personal command(...)), but Google does not document a default sandbox difference beyond that syntax. Non-workspace access defaults to false on both surfaces. Details: Antigravity sandbox and agent settings.

The sandbox limits terminal commands. It does not replace hook-based DLP for file tools or browser subagents.

MCP tokens

MCP configuration lives in ~/.gemini/config/mcp_config.json. OAuth tokens for MCP are stored under ~/.gemini/antigravity/mcp_oauth_tokens.json. Treat both like credential stores—same rotation and access-review discipline as API keys. See Antigravity MCP.

Transcripts

Session logs are written under paths such as:

~/.gemini/antigravity-cli/brain/<session-id>/.system_generated/logs/transcript.jsonl

Google has used more than one folder name across versions (antigravity-cli, antigravity, antigravity-ide). ReclaimLLM’s historical sync checks those variants when backfilling. Provider-owned transcripts may retain unredacted content even when hooks sanitize uploads—plan retention and disk encryption accordingly. For a cross-tool transcript map, see AI coding transcripts as a secret store.

Known exfiltration research

PromptArmor demonstrated indirect prompt injection: hidden instructions in web content coerced Antigravity to read .env credentials and exfiltrate them via attacker-controlled URLs reached through a browser subagent. At research time, webhook.site appeared in Antigravity’s default Browser URL Allowlist (browser docs). As of our October 2026 check, PromptArmor’s write-up did not document a vendor fix—say “no fix documented as of [your check date],” not “patched” or “still vulnerable forever.”

Operational mitigations either way: tighten browser allowlists, block env reads at PreToolUse, and monitor outbound network patterns.

Codex security

Hooks

Codex enables hooks by default. To disable them in config.toml:

[features]
hooks = false

Non-managed hooks require review and trust via /hooks before they run. Managed hooks arrive through requirements.toml and MDM. Project-local hooks load only when the project .codex/ layer is trusted; user and system hooks still load from their own config layers when the project is untrusted.

PreToolUse can deny or rewrite input. OpenAI’s docs state explicitly that “an explicit supported denial can block an action, but a PreToolUse callback error, timeout, or malformed response can fail the hook without blocking the tool.” PostToolUse cannot undo side effects; errors, missing servers, and unavailable tools do not block the operation.

Canonical references (October 2026): Codex hooks and Agent approvals & security. Older developers.openai.com/codex/* URLs redirect to learn.chatgpt.com; cite the learn URLs in new docs.

Sandbox and approvals

Named sandbox modes:

Mode	Behavior
`read-only`	Inspect files; no edits or commands without approval
`workspace-write`	Default — edits and routine local commands within project boundaries
`danger-full-access`	Removes filesystem and network restrictions

Approval policies: on-request (sandboxed by default, asks to go beyond the boundary) and never. An approvals_reviewer can be user or auto_review.

OpenAI documents Work Cloud toggles such as “Allow public internet access,” but does not state a default network-access policy for the sandbox itself in the material we reviewed—do not claim “network blocked by default” without checking your org’s current Codex settings page.

Transcripts

Full session transcripts live at:

~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl

Codex also maintains a separate prompt index at ~/.codex/history.jsonl. ReclaimLLM’s rclm-sync imports session JSONL under sessions/; it does not import history.jsonl as a full session source. Align purge policy with both files if developers use Codex daily.

Antigravity vs Codex: hooks and sandboxes

Capability	Antigravity	Codex
Pre-tool deny	Yes (PreToolUse)	Yes (PreToolUse)
Rewrite tool input	Yes (overwrite)	Yes (`updatedInput`)
Redact tool output in PostToolUse	No (no output in hook payload)	No (cannot undo side effects)
Hook crash/timeout behavior	Undocumented by Google	Documented: can fail without blocking the tool
Trust model	Project/user hook files	`/hooks` review + trust; managed via `requirements.toml`
Sandbox default	App: on; CLI (`agy`): off (auto may enable)	`workspace-write`; network default undocumented

Neither column replaces secret scanning in CI or vault-backed credentials. Both need explicit env and egress policy.

How ReclaimLLM fits Antigravity and Codex

ReclaimLLM’s Antigravity integration is shipped, not a preview: default rclm-hooks-install includes Antigravity with PreInvocation, PostInvocation, PreToolUse, PostToolUse, and Stop.

On PreToolUse for Antigravity, ReclaimLLM runs:

Env DLP — denies view_file, write_to_file, and replace_file_content on recognized env paths; blocks run_command patterns that dump environment files.
Egress guard — blocks common exfiltration binaries and inline fetch patterns toward non-allowlisted destinations, plus a GeoIP country firewall (announcement).

The same egress guard covers Codex on PreToolUse. For post-hoc egress anomaly detection, AD-015’s shipped client list names Claude Code, Cursor, Codex CLI, GitHub Copilot, Gemini CLI, Windsurf, and OpenCode—it does not list Antigravity. Use hooks + egress guard for Antigravity prevention; use capture and signals for broader detection. See AD-015.

Capture: rclm-sync --antigravity backfills transcripts; live Stop hooks upload sessions. Provider transcripts on disk may stay unredacted—ReclaimLLM redacts on upload per local redaction, but treat local files as sensitive.

Two different “fail” modes (do not conflate them)

When ReclaimLLM’s env DLP hook runs and recognizes a blocked env access pattern, it denies that tool call—fail-closed for that class of event.

When the hook process crashes, times out, or the vendor hook runner errors, behavior follows vendor rules. Codex documents fail-open hook callbacks in several cases; Antigravity’s runner behavior on error is undocumented. ReclaimLLM coverage is detection, not MDM—you still want coverage alerts when hooks go missing.

ReclaimLLM data residency is US and EU only. SOC 2 Type II is targeted for early 2027; ReclaimLLM is not yet certified.

Checklist for Antigravity and Codex

#	Control	Antigravity	Codex
1	Pre-tool hooks for env + egress	Install RCLM hooks; review Google hook JSON	Trust project hooks; install RCLM hooks
2	Sandbox / approvals	App: confirm sandbox on; CLI: set `enableTerminalSandbox` explicitly	Avoid `danger-full-access`; prefer `on-request`
3	Browser / network allowlists	Review default browser allowlist; remove test domains	Confirm Work Cloud network toggle with security
4	MCP credential hygiene	Rotate `mcp_oauth_tokens.json` on schedule	Review managed `requirements.toml` hooks
5	Transcript retention	Encrypt disk; purge `~/.gemini/.../transcript*.jsonl`	Purge `sessions/` and decide on `history.jsonl`
6	Coverage verification	Coverage tab + device check-in	Same
7	Incident evidence	Signals + session replay	AD-015 where supported

For a deeper network-exfiltration playbook, see Stopping AI agent network exfiltration.

Next step: Block secret exfiltration in Antigravity and Codex—start free.

FAQ

Is Google Antigravity secure for company code?

It can be, when you combine sandbox settings (surface-dependent defaults), hook denies, browser allowlists, MCP hygiene, and monitoring. Google documents the knobs; your team owns enforcement and verification. No agent is safe if developers paste live secrets into prompts.

Is Gemini CLI still available?

Yes for Gemini Code Assist Standard/Enterprise and paid API-key users. Consumer Pro/Ultra and free individual access moved to Antigravity CLI on June 18, 2026. Enterprise CLI users are not automatically on agy.

Do Antigravity hooks fail open?

Google does not document crash, timeout, or malformed-output behavior for its hook runner as of October 2026. ReclaimLLM env DLP denies recognized env reads when our hook runs successfully—it does not change undocumented Google runner behavior.

Can Codex hooks block a command?

Yes—a supported PreToolUse deny blocks the action. Hook callback errors, timeouts, or malformed responses can fail the hook without blocking the tool, per OpenAI’s documentation.

Where are Antigravity MCP OAuth tokens stored?

In ~/.gemini/antigravity/mcp_oauth_tokens.json, alongside MCP config in ~/.gemini/config/mcp_config.json. Back them into access-review and rotation procedures like any other secret file.

Does ReclaimLLM’s AD-015 cover Antigravity?

No. AD-015’s published integration list does not include Antigravity. Use PreToolUse egress guard and env DLP for Antigravity, plus session capture for audit evidence.

Read the original article at ReclaimLLM.

OpenTelemetry is the right interface for LLM APIs — but not for coding agents

Momin Aziz — Sat, 31 Oct 2026 14:33:56 +0000

Originally published on ReclaimLLM: https://reclaimllm.com/blogs/opentelemetry-llm-apis-vs-native-coding-agents

Why application-owned LLM calls belong in OpenTelemetry, while developer coding assistants require native lifecycle hooks, patch hunks, and terminal context.

OpenTelemetry is the right interface for LLM APIs — but not for coding agents

Enterprises are adopting two very different kinds of AI systems at the same time.

The first is software they build: support workflows, copilots, extraction pipelines, internal agents, and other applications that call OpenAI, Anthropic, Gemini, Azure OpenAI, Vertex AI, Bedrock, or another model API.

The second is software their developers use: Claude Code, Codex CLI, Cursor, Antigravity, Gemini CLI, and OpenClaw.

Both create prompts, responses, tool calls, token usage, errors, and governance questions. But they should not be captured in the same way.

For application-owned LLM calls, OpenTelemetry is the right integration boundary. For coding agents, native hooks and transcripts contain materially richer information. ReclaimLLM supports both paths and normalizes them into the same session model.

Use OpenTelemetry Where the Application Owns the Call

An enterprise application already has a provider integration, deployment architecture, and security review. Adding observability should not require replacing that provider client or inserting a new inference gateway.

With OpenTelemetry, the paths remain separate:

Application ──→ LLM provider
     │
     └── OTLP/HTTP traces ──→ ReclaimLLM

The application continues to send inference traffic directly to its provider. An OpenTelemetry SDK or Collector exports the telemetry around that call to ReclaimLLM.

This works well for teams that:

Already operate an OpenTelemetry Collector;
Use multiple model providers;
Cannot add another service to the inference path;
Want application traces and LLM activity to share correlation context;
Need team attribution without transferring provider credentials.

ReclaimLLM accepts OpenTelemetry GenAI and OpenInference traces over OTLP/HTTP. Depending on what the instrumentor emits, the resulting session can include prompts, responses, tool calls, models, token usage, timing, errors, span relationships, and custom workflow attributes.

Related calls are grouped using session.id, then gen_ai.conversation.id, and finally the trace ID. Re-exported spans converge by trace and span identity, so normal Collector retries do not create duplicate conversations or inflate usage totals.

Coding Agents Expose a Different Surface

A coding agent is not just another model API.

Its useful context lives in local transcript files and proprietary lifecycle hooks rather than standard spans. That context includes:

File edits and patch hunks;
Terminal commands and their results;
Working-directory and repository context;
Permission decisions;
Session resume and stop events;
Client-specific token counters;
Tool-result transformations that happened before content reached the model.

Reducing these sessions to generic OTLP would discard critical detail or depend on each client emitting the same stable telemetry. They do not.

ReclaimLLM uses independently versioned native adapters for Claude Code, Codex CLI, Cursor, Antigravity, Gemini CLI, and OpenClaw. Each adapter follows the source contract that client actually provides. A transcript can be primary for one client while hook reconstruction is the best available source for another.

Installation uses one package and one command:

pip install rclm
rclm-hooks-install

The default installer configures Claude Code, Codex CLI, Cursor, Antigravity, and Gemini CLI. OpenClaw is opt-in via --openclaw.

One Downstream Model, Explicit Provenance

Separate capture paths should not create separate products.

After normalization, OpenTelemetry and native-agent records use the same ReclaimLLM session, message, tool-call, usage, storage, search, and governance systems. Existing encryption, data residency, retention, authorization, export, and deletion controls apply to both.

The source remains explicit through three independent dimensions:

capture_source identifies opentelemetry or native_agent;
agent_client identifies Cursor, Claude Code, Codex, Antigravity, Gemini CLI, or OpenClaw;
The model provider identifies the company serving the model.

These fields should not be collapsed. A developer can use Cursor with a Claude model. In that case, Cursor is the client and Anthropic is the model provider. Inferring the client from the model would produce incorrect analytics.

What Teams Should Deploy

Use OpenTelemetry for production applications and internal workflows where your code owns the provider request. If a Collector already exists, add ReclaimLLM as another trace destination and retain the current batching, filtering, redaction, and retry pipeline.
Use native capture for developer coding agents when you need the richer client session: transcript content, tools, code changes, project context, and lifecycle events.

The design principle is simple: standardize where the ecosystem has a useful standard, preserve native detail where it does not, and normalize only at the point where the data can honestly share a model.

Originally published at https://reclaimllm.com/blogs/opentelemetry-llm-apis-vs-native-coding-agents

Why .cursorignore is not DLP

Momin Aziz — Sat, 31 Oct 2026 14:30:56 +0000

Originally published on ReclaimLLM: https://reclaimllm.com/blogs/why-cursorignore-is-not-dlp

Cursor can still read .env files, see terminal output, and send context to the model even when Privacy Mode is on — ignore files are not redaction.

Why .cursorignore is not DLP

.cursorignore is useful. It is not DLP.

Teams often treat an ignore file as a security control: add .env, ship a PR, and assume Cursor cannot expose secrets. That assumption fails in the places that matter for AI coding assistants — file reads the agent still performs, shell output the model still sees, and privacy settings that change retention without redacting prompts.

What .cursorignore actually does

Ignore files tell the editor which paths to de-emphasize for indexing and some context features. They do not:

Intercept tool calls that read files
Scrub secrets from terminal or command output before they enter the model context
Replace credentials with typed placeholders so the assistant can keep working without the raw secret
Produce an audit trail of what was blocked or redacted

If an agent (or a developer) opens .env, pastes a key, or runs a command that prints a token, the ignore list does not rewrite that content on the way out.

Terminal bypass and agent file reads

Modern Cursor workflows are tool-heavy. Agents read files, run shell commands, and summarize results. Secrets commonly appear in:

.env / .envrc and sibling env files
printenv, cat, and deploy scripts
CI logs and local debug output pasted into chat

An ignore entry does not sit on that path. For a control that does, see Cursor Security & DLP and the AI coding assistant DLP overview.

Privacy Mode is not redaction

Privacy Mode and similar product settings typically change how prompts may be retained or used by the vendor. They do not mean “strip API keys from this turn before the request leaves the machine.”

Redaction and retention are different layers:

Control	What it changes
`.cursorignore`	Indexing / some context inclusion hints
Privacy Mode	Vendor retention / training posture
Hook DLP	Content rewritten locally before egress

If your requirement is “plaintext secrets must not reach the model,” you need a pre-execution control — not an ignore file.

What hook DLP does instead

ReclaimLLM installs hooks for Cursor (and other assistants) so high-risk reads and shell outputs can be redacted on the device before they are sent. Matched credentials are replaced with labeled placeholders such as [REDACTED:API_KEY] while preserving enough structure for the assistant to continue. Configure substitutions and folder filters as described in sensitive data docs.

Install Cursor hooks with:

rclm-hooks-install --cursor

For the governance picture — redaction at the hook, sensitive-session handling, and gateway options — see DLP governance.

Bottom line

Use .cursorignore for hygiene. Use hook DLP when the threat model is secret egress to Cursor’s model. Privacy Mode does not close that gap.

Originally published at https://reclaimllm.com/blogs/why-cursorignore-is-not-dlp

Prevent API keys and .env from reaching ChatGPT, Cursor, and Claude Code

Momin Aziz — Sat, 31 Oct 2026 14:28:02 +0000

Originally published on ReclaimLLM: https://reclaimllm.com/blogs/prevent-api-keys-env-from-ai-coding-tools

A practical how-to: stop secrets in env files and shell output from leaving the workstation when developers use ChatGPT, Cursor, or Claude Code.

Prevent API keys and .env from reaching ChatGPT, Cursor, and Claude Code

API keys and .env contents show up in AI coding sessions more often than security reviews expect — not because developers are reckless, but because agents read files and run commands by default.

This guide covers what usually leaks, what ignore lists and chat settings do not stop, and how hook DLP redacts secrets before they reach ChatGPT, Cursor, or Claude Code.

Where secrets enter the model context

Common paths:

File reads — the agent opens .env, .env.local, .envrc, or a config that embeds a token
Shell output — env, printenv, failed deploys, or scripts that echo credentials
Paste — a key lands in the prompt during debugging
Browser assistants — ChatGPT / Claude.ai threads fed from the same repo context via copy or extensions

If the control only filters search indexes, those paths still send plaintext to the provider.

What does not solve it alone

.cursorignore / .gitignore — hygiene for indexing and git; not egress redaction. See why .cursorignore is not DLP.
“Do not train on my data” toggles — retention posture, not secret stripping
Hoping developers never open .env — agents open files without a human click

You need a control that rewrites high-risk content before the request leaves the machine.

Hook DLP: redact at the tool boundary

ReclaimLLM hooks sit at the assistant’s tool/file/shell boundary. For supported CLIs and editors (including Cursor and Claude Code), matched secrets in file reads and command output can be replaced with labeled placeholders such as [REDACTED:API_KEY] so the model never receives the raw value.

Configure substitutions and folder include/exclude filters in sensitive data docs. Sync shared rules with rclm-update after changing Global Substitutions in the app.

Install hooks:

rclm-hooks-install --cursor
rclm-hooks-install --claude

Browser and API paths differ: ChatGPT-style workflows need capture/proxy coverage rather than native Cursor/Claude hooks — see AI coding assistant DLP and install.

After capture: review and sensitive handling

Hook redaction is the primary prevention layer. Sessions that still look sensitive can be reviewed before share or export; Enterprise plans add org-oriented DLP scanning. Details and current limitations are documented under sensitive data.

For the full control stack — redact at hook, sensitive session handling, and gateway options — read DLP governance and Claude Code DLP & hooks.

Checklist

Inventory which tools engineers use (Cursor, Claude Code, ChatGPT, Copilot, Gemini)
Install hooks where native support exists
Add env-file and high-entropy patterns to redaction substitutions
Restrict capture folders if needed (include_folders / exclude_folders)
Verify with a test session that placeholders appear instead of plaintext keys

Prevention is local and deterministic for known patterns. Treat vendor privacy modes as complementary, not sufficient.

Originally published at https://reclaimllm.com/blogs/prevent-api-keys-env-from-ai-coding-tools

Hook DLP vs endpoint AI DLP vs AIDR

Momin Aziz — Sat, 31 Oct 2026 14:25:03 +0000

Originally published on ReclaimLLM: https://reclaimllm.com/blogs/hook-dlp-vs-endpoint-ai-dlp-vs-aidr

A fair comparison for evaluation queries: tool-level hook redaction, OS/endpoint AI DLP agents, and network AIDR/CASB-style controls — what each sees and misses.

Hook DLP vs endpoint AI DLP vs AIDR

Buyers evaluating “AI DLP” often compare three architectures that sound similar in a slide deck and behave differently on a developer laptop.

This article maps hook DLP, endpoint AI DLP, and AIDR / network DLP without claiming one product is universally “best.” For a productized side-by-side, see also Hook DLP vs Endpoint DLP.

Definitions

Approach	Where it sits	Typical strength
Hook DLP	Inside the coding assistant’s tool/file/shell hooks	Sees structured agent I/O; can redact before model egress
Endpoint AI DLP	OS agent / EDR-adjacent sensors on the device	Broad process visibility; heavier footprint; may miss app-native tool schemas
AIDR / network DLP / CASB	Proxy, gateway, or cloud API inspection	Strong for SaaS HTTP paths; weak for local CLI tool loops that never hit that proxy

Hook DLP

Hooks run at the assistant boundary: file reads, shell results, and related tool payloads can be inspected and rewritten locally. ReclaimLLM uses this model for Cursor, Claude Code, and other supported assistants — replacing secrets with placeholders such as [REDACTED:API_KEY] before the request leaves the machine (sensitive data docs).

Fits well when: the risk is .env and terminal secrets in agent loops; you want low friction for developers; you need typed redaction that keeps sessions usable.

Limits: coverage depends on hook support per tool; browser ChatGPT threads and unmanaged apps need other paths (AI coding assistant DLP).

Endpoint AI DLP

Endpoint products instrument the OS: process trees, clipboard, file access, sometimes screen or keystroke-adjacent signals. They can catch exfiltration that never uses a coding-assistant hook.

Fits well when: you already standardize on an endpoint stack and need cross-application coverage beyond IDEs.

Limits: coding agents speak structured tool protocols; generic sensors may alert late, miss semantic context, or create noise. They rarely provide assistant-aware placeholders that preserve agent syntax. Fair evaluation should test secret-in-.env-via-agent, not only file copy to USB.

AIDR / network DLP / CASB

Network and API controls inspect traffic to known LLM SaaS endpoints. They work when traffic is forced through the inspection point and payloads are visible (not end-to-end opaque in a way that blocks inspection).

Fits well when: cloud ChatGPT / API usage is the dominant path and TLS interception or provider APIs are in scope.

Limits: local CLI agents, editor-embedded models, and bypass networks can avoid the chokepoint. Cursor/Claude Code tool loops often look like “developer workstation → provider” without a corporate proxy in the middle unless you force one.

Evaluation questions (fair tests)

Does the control see agent file reads of .env, or only bulk file exfil?
Does it redact before model ingest, or only alert after?
What is the developer friction (agents broken vs placeholders)?
Which tools in your inventory (Cursor, Claude, Copilot, Gemini, browser) are actually in path?
Can you produce evidence for review — sessions, redaction config, gateway logs?

Use DLP governance for the hook + sensitive-session + gateway stack, and security & compliance for org design.

Practical recommendation

Most engineering orgs need layered controls: hook DLP for coding agents, endpoint for broader device risk, network/AIDR for sanctioned SaaS HTTP. Treat them as complementary. Evaluate with real Cursor/Claude workflows, not only generic web-chat proxies.

Originally published at https://reclaimllm.com/blogs/hook-dlp-vs-endpoint-ai-dlp-vs-aidr

The compliance debt of AI coding agents

Momin Aziz — Sat, 31 Oct 2026 14:22:07 +0000

Originally published on ReclaimLLM: https://reclaimllm.com/blogs/ai-coding-compliance-and-regulatory-risks

How autonomous file reads break GDPR data sovereignty, SOC 2 least privilege, audit trails, and sector mandates — with the checklist auditors look for.

The compliance debt of AI coding agents

When engineering teams equip autonomous coding agents with repository access and shell execution, the focus is almost always on developer velocity: faster PRs, automated refactoring, and instant bug triage.

The compliance failure happens in the background.

When a developer asks an agent to debug a failed database migration or configure an integration, the agent does what any capable system would do: it inspects the project environment. It reads .env, parses .env.production, or inspects local shell configuration files.

To a developer, the agent is simply reading a configuration file. To an auditor, that single action frequently breaks regulatory and governance controls across data sovereignty, access control, and incident logging frameworks.

The issue is not that AI tools are inherently non-compliant. The issue is that autonomous agents operate under human workstation privileges while lacking human accountability, and they route sensitive local state into external model provider networks.

Here is an analysis of how autonomous coding agents trigger regulatory findings across five specific compliance areas, along with what auditors flag during an enterprise assessment.

1. Data Residency and Sovereignty Violations (GDPR, PIPEDA, CCPA)

The Mechanism:
When an AI coding agent reads a configuration file, its contents are packaged into an API payload and sent to external model provider inference endpoints. These endpoints are frequently hosted in US data centers or distributed multi-region cloud clusters.

The Failure:
Reading a generic configuration like PORT=8000 is harmless. However, .env and configuration files regularly contain:

Database connection strings that include user credentials
Internal customer identifiers and staging URLs
Third-party webhook tokens and API secrets

Under frameworks like the EU General Data Protection Regulation (GDPR Chapter V) or Canada's PIPEDA, transmitting data that unlocks access to personal data across international borders requires specific contractual mechanisms: valid Data Processing Agreements (DPAs) with approved Standard Contractual Clauses (SCCs).

If an agent running on a European developer’s laptop reads an environment file containing credentials to an EU customer staging database and ships that context to an unvetted cloud model endpoint outside the EEA, that transfer represents an unauthorized cross-border disclosure.

2. Breach of Least Privilege and Access Control (SOC 2, ISO/IEC 27001)

The Mechanism:
Standards such as SOC 2 (Trust Services Criteria CC6.1, CC6.2, CC6.3) and ISO/IEC 27001 (Controls A.9 and A.8 in updated revisions) mandate strict enforcement of the Principle of Least Privilege (PoLP) and segregation between production and development secrets.

The Failure:
Autonomous agents run with the elevated shell permissions of the developer who launched them. An agent can read, write, and execute anything that the developer's user account can access on the workstation.

In an audit, exposing live credentials to automated tooling invalidates compliance evidence:

Plaintext Secret Exposure: Storing production or staging secrets in plaintext workspace files accessible by autonomous processes violates controls requiring encryption at rest and role-based segregation.
Inherited Privilege Without Identity: The agent possesses no individual cryptographic identity or role boundary. It acts as an unvetted extension of the developer, bypassing access tiering. If an agent accesses staging or production keys that only senior engineers are authorized to touch directly, the control fails.

3. Destruction of Forensic Auditability and Non-Repudiation

The Mechanism:
Enterprise compliance frameworks require an immutable audit trail detailing who accessed sensitive resources, when, and for what purpose.

The Failure:
When an AI coding agent executes a tool call—such as cat .env.production or a Python open(".env") call—the operation is recorded in the local operating system log only under the developer’s local username, or in ephemeral terminal history.

If those credentials leak, identifying the causal chain is nearly impossible:

Was the secret accessed intentionally by the human engineer?
Was it read autonomously by a background agent tool loop trying to solve a build error?
Did the prompt payload include the secret, and was it cached in a third-party model context window?

The agent acts as an unmonitored proxy. It breaks non-repudiation and makes forensic analysis during a security incident report impossible to reconcile with auditor expectations.

4. Third-Party Vendor Risk and Subprocessor Sprawl

The Mechanism:
Enterprise vendor management policies require vetting and approving every third-party service provider that processes confidential code or infrastructure secrets.

The Failure:
Even when an enterprise signs a commercial Zero Data Retention (ZDR) agreement with an LLM provider (such as Anthropic, OpenAI, or Google Cloud Vertex AI), secrets transmitted in prompt payloads can remain vulnerable:

Ephemeral Debug and Error Caches: Provider-side infrastructure often retains short-term operational logs, error traces, and intermediate proxy buffers.
Shadow Vendor Integration: Developers switching between different coding assistants (Cursor, Claude Code, Gemini CLI, or custom MCP servers) may inadvertently route secrets through providers and intermediate gateways that have never undergone internal vendor security review.

When an unredacted secret is sent across an API boundary to an unapproved model endpoint, that endpoint becomes an unauthorized subprocessor.

5. Critical Infrastructure and Sector-Specific Mandates (NERC CIP, HIPAA, PCI-DSS)

In regulated industries, transmitting infrastructure secrets through cloud-connected AI tooling can turn an operational session into a reportable incident:

PCI-DSS (Requirements 3 & 8): Payment card data, database connection strings, and API keys granting access to cardholder data environments (CDE) must never be stored in plaintext or exposed to untrusted external networks. If an agent loads database credentials connected to payment processing infrastructure into a model prompt, it violates network isolation and secret protection requirements.
HIPAA (Security Rule 45 CFR Part 164): Transmission of environment variables containing tokens that decrypt or access Electronic Protected Health Information (ePHI) without an executed Business Associate Agreement (BAA) with the specific LLM provider can constitute an unauthorized disclosure under HIPAA breach notification rules.
NERC CIP (CIP-004, CIP-007, CIP-011): In energy and utility environments, Information Protection programs require rigorous isolation of Bespoke Cyber System Information (BCSI). Exposing system access keys, SCADA connection strings, or OT network credentials to public cloud AI tools violates mandatory access control and incident response standards.

Summary Checklist for Enterprise Auditors

When an auditor evaluates an engineering team utilizing autonomous AI coding agents, they look for four specific breakdown indicators:

Compliance Area	What Auditors Check	Audit Risk Finding
Plaintext Storage	Presence of `.env` and credential files in workspace directories accessible by unmonitored agent processes.	Breakdown of secret vault controls and failure of credential encryption at rest.
Uncontrolled Exfiltration	Outbound network payloads from agent tools containing raw credentials, tokens, or connection strings.	Unauthorized data transfer and failure of network perimeter controls.
Logging & Retention	API keys or passwords appearing in LLM prompt histories, IDE telemetry, or context cache logs.	Violation of data retention policies and exposure of sensitive material to third parties.
Access Governance	Autonomous agent tools executing with developer-level privileges without distinct identity or least-privilege scoping.	Failure of Role-Based Access Control (RBAC) and destruction of non-repudiation.

The Engineering Remedy: Defending Before the Boundary

Addressing these compliance exposures cannot mean banning AI coding tools. Developers will continue to use them, and the productivity advantages are significant.

Instead, compliance must be enforced at the interface boundary:

Pre-Execution Redaction: Sensitive files (.env, .envrc, *.pem) must have credentials masked locally ([REDACTED:API_KEY]) before they can be ingested into model context or transmitted across the wire.
Deterministic Detection: Workflows must be audited for both direct tool reads and agent-written scripts (such as Python load_dotenv() workarounds) using deterministic anomaly detectors like ReclaimLLM's AD-004.
Session-Level Auditability: Every tool invocation, shell command, and model interaction must be attributed to an immutable session record tied to the developer, project, and organization.

Without local DLP and session-level observability, AI coding agents remain a compliance blind spot waiting for an audit finding.

Originally published at https://reclaimllm.com/blogs/ai-coding-compliance-and-regulatory-risks

The agentic blind spot: detecting AI secret exfiltration

Momin Aziz — Sat, 31 Oct 2026 14:18:58 +0000

Originally published on ReclaimLLM: https://reclaimllm.com/blogs/detecting-ai-agent-secret-exfiltration-ad004

Why monitoring file-read tools misses agent execution loops: how coding agents use shell pipelines and shadow scripts like load_dotenv() — and how AD-004 detects them.

The agentic blind spot: detecting AI secret exfiltration

Most enterprise security tooling evaluates developer environments using static assumptions: inspect the repo with SAST, scan commits with git hooks, and monitor endpoint file system access.

Autonomous AI coding agents render those assumptions obsolete.

An agent is not a static script. It is an iterative reasoning engine paired with tool execution. When an agent is tasked with fixing an API endpoint or setting up a database test, it attempts to resolve missing configuration variables dynamically.

If an enterprise restricts direct file-read tools or monitors native file system events, the model does not simply give up. It adapts. It writes a temporary Python script that loads .env.production into memory. It runs a shell command that pipes credentials through sed or grep. Or it creates a temporary Bash script that sources environment variables and prints them.

To traditional security tooling, this looks like normal code generation: a file named runner.py was created and run. Underneath, production credentials and cloud secrets were loaded into the model's runtime context.

To solve this, observability cannot merely watch file system reads. It must inspect the entire agentic execution loop across three distinct operational surfaces.

The Three Surfaces of Sensitive File Access

In ReclaimLLM Enterprise, we designed AD-004: Sensitive File Access Detection to scan completed sessions deterministically. Rather than relying on fuzzy machine learning or heuristic guesses, AD-004 inspects three specific surfaces where secrets cross from the local workstation into agent context:

┌────────────────────────────────────────────────────────┐
│                   AI Coding Agent                      │
└──────┬───────────────────┼──────────────────────┬──────┘
       │ Surface 1         │ Surface 2            │ Surface 3
       ▼                   ▼                      ▼
 Direct Tool Access   Shell Command Access   Code & Script Mentions
 • readFile(.env)     • cat .env.production  • load_dotenv(".env")
 • writeFile(.envrc)  • sed -n 'p' dev.env   • open(".env").read()
 • *.pem, id_rsa      • rg "KEY" .env        • source .env && run

Surface 1: Direct Tool Access

What happens:
The agent natively calls a built-in file inspection tool (readFile, view_file, edit_file) targeting known credential files.

Target patterns detected:

Environment files: .env, .env.*, *.env, .envrc
Private keys and certificates: *.pem, *_rsa, *id_rsa, *.p12
Service account secrets: *credentials*.json, *service-account*.json

The Governance Check:
AD-004 does not merely check if the file was accessed; it correlates each access with Pre-Execution Hook DLP status (was_redacted) so investigators can separate covered reads from DLP gaps.

Sensitive file reads and code_mention events produce a Warning finding — including when DLP redacted secrets to [REDACTED:API_KEY] before model ingestion. Redaction is investigation context, not a separate severity gate.
Writes to sensitive paths (or write-style code mentions such as open(".env", "w")) escalate to High.
Critical requires multiple sessions with env-file activity and at least one session with no DLP coverage — a gap where secrets or scripts referencing them may have reached an external provider.
Capture-only clients (for example Gemini or Antigravity) may lack pre-execution DLP; treat sensitive-file activity there as a potential coverage gap regardless of was_redacted.

Surface 2: Shell Command Extraction

What happens:
When native file tools are unavailable, restricted, or when the agent defaults to terminal commands, it uses shell utilities to extract file contents:

cat .env.production
head -n 20 .envrc
sed -n '/DATABASE/p' dev.env
rg "AWS_SECRET" .env

This represents one of the most common real-world leak vectors in autonomous coding sessions. A developer asks, "Why is the S3 upload failing?" The agent runs cat .env in the terminal to inspect the bucket configuration, dumping the live AWS_SECRET_ACCESS_KEY into terminal stdout.

That stdout is packaged into the agent's next message payload and sent directly to the model provider. Because this occurred inside a shell execution command, simple file-read monitors miss it entirely.

AD-004 parses shell command arguments and pipelines, identifying sensitive file references across terminal executions and flagging them as shell_read access events.

Surface 3: Code and Script Mentions (The Agent Blind Spot)

What happens:
The agent generates code that opens, loads, or sources a sensitive file—frequently writing a temporary helper script to disk and executing it in the background:

# Temporary script written by an agent to verify connection
from dotenv import load_dotenv
import os

load_dotenv(".env.production")
conn_str = os.environ.get("DATABASE_URL")
# Agent runs this script to inspect connection behavior

# Agent writes and runs a quick setup helper
source .env && echo "Loaded config for $APP_ENV"

This surface is critical because traditional hook DLP operates on inputs and outputs at the boundary. When a model writes a Python script that references .env as a string literal, no secret passes through the hook at generation time.

However, the script itself becomes the exfiltration vector the moment the agent executes it: the Python interpreter reads the secret into memory, outputs it during debugging, or passes it back through runtime exceptions.

AD-004 scans tool outputs and agent-written files for code constructs, file path literals, load_dotenv() invocations, and source .env expressions, recording them as distinct code_mention events.

Deterministic Severity Without Black-Box Guesswork

Many AI governance tools rely on secondary LLMs to classify security risks. This introduces two fatal flaws into enterprise compliance:

Non-reproducible findings: An LLM might flag an access today and miss it tomorrow.
Data leakage in detection: Sending prompt telemetry to another LLM to check if it contains secrets multiplies subprocessor risk.

AD-004 is completely deterministic. It executes nightly over session metadata and evaluates explicit rules:

Severity	Threshold Criteria	Recommended Action
Warning	One or more sessions contain a sensitive file read or `code_mention` where DLP coverage was verified (`was_redacted: true`).	Review during routine morning digest. Verify that access was part of legitimate local development.
High	At least one session executed a write operation to a sensitive file path, or the code mention involves overwriting environment variables (`open(".env", "w")`).	Investigate whether an agent altered local security credentials or corrupted configuration state.
Critical	Multiple sessions exhibit sensitive file activity and at least one session had no DLP coverage (`was_redacted: false`).	Immediate incident escalation. Secrets may have traveled unmasked to external model provider endpoints.

Privacy by Design in Security Reporting

An alert system should never cause a secondary security incident.

When AD-004 detects an unredacted secret or an agent script reading .env, what does it record in the finding evidence?

Evidence includes: Session count, access types (read, write, shell_read, code_mention), matched file pattern categories (env_file, private_key), DLP coverage status, and authenticated session IDs.
Evidence NEVER includes: Actual file paths, raw secrets, passwords, script source code, or prompt text.

Security administrators receive bounded, explainable evidence that allows them to click through authenticated portal deep links directly to the offending session trace—without sensitive data ever leaving the encrypted storage boundary.

How Security Teams Close the Gap

Verify Hook DLP Enforcement: Ensure all developer workstations run native hooks with default-on DLP (rclm-hooks-install).
Monitor AD-004 High & Critical Findings: Filter the Signals dashboard to identify sessions where agents bypassed direct file tools via shell extractions or temporary Python runners.
Trace the Execution Context: Open the linked session evidence to review the developer's objective, the tool sequence, and whether the script was executed within a protected boundary.

Autonomous coding agents are formidable engineering multipliers. But if your security architecture only monitors direct tool reads, you are looking at a fraction of the actual execution loop.

Originally published at https://reclaimllm.com/blogs/detecting-ai-agent-secret-exfiltration-ad004

The enterprise AI control plane: moving from risk to audit-ready

Momin Aziz — Sat, 31 Oct 2026 14:16:10 +0000

Originally published on ReclaimLLM: https://reclaimllm.com/blogs/enterprise-ai-coding-security-control-plane

Why blanket AI bans fail: a four-layer defense across pre-execution hook DLP, governed gateways, customer-key encryption, and multi-cadence alerting.

The enterprise AI control plane: moving from risk to audit-ready

When security and compliance teams realize that autonomous AI coding agents can read .env files, execute shell extraction pipelines, and pipe credentials to external model providers, the initial enterprise reaction is often administrative restriction: ban AI coding tools or block provider domains at the firewall.

This strategy fails in practice.

Engineers under pressure to deliver software will route around network firewalls using personal hotspots, copy sensitive context into browser-based assistants, or disable internal security scanners. Blanket bans create shadow AI workflows that strip security teams of visibility.

The viable enterprise path is not prohibition. It is building an active control plane that establishes guardrails at the execution boundary, prevents secret exfiltration before network transit, and provides deterministic audit evidence.

Here is how ReclaimLLM structures a four-layer defense architecture to enable developer AI velocity while meeting enterprise compliance standards.

The Four Layers of Enterprise AI Defense

┌─────────────────────────────────────────────────────────────────┐
│                   Developer Workstation                         │
│  [ Native Agent Hooks: Pre-Execution Hook DLP ]  ← LAYER 1      │
│  • Recursively scrubs .env, *.env, .envrc                       │
│  • Replaces credentials with [REDACTED:API_KEY]                 │
└───────────────────────────────┬─────────────────────────────────┘
                                │ Scrubbed Payload
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│                 Enterprise LLM API Gateway       ← LAYER 2      │
│  • Provider master keys never touch workstations                │
│  • Issues team-scoped, model-restricted gateway tokens          │
└───────────────────────────────┬─────────────────────────────────┘
                                │ Governed Ingest
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│                 Encrypted Storage & Residency    ← LAYER 3      │
│  • AES-256 transcript blobs with Customer Recovery Keys         │
│  • US / EU cloud data residency or On-Prem VPC (Docker/Helm)    │
└───────────────────────────────┬─────────────────────────────────┘
                                │ Evaluated Metadata
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│           Deterministic Anomaly Engine & Alerts  ← LAYER 4      │
│  • AD-004 Sensitive File Access detection                       │
│  • Multi-cadence alerting: Immediate criticals, 08:00 digest    │
│  • Zero raw secrets in email payloads; deep links to portal     │
└─────────────────────────────────────────────────────────────────┘

Layer 1: Local Pre-Execution Hook DLP (Hiding Secrets Before Transit)

The safest place to stop credential exfiltration is on-device, before payloads are packaged into network requests.

ReclaimLLM installs lightweight native hooks into developer environments (rclm-hooks-install). Whenever an agent or developer tool attempts to read or execute commands against files matching .env, .env.*, or .envrc, the hook intercepts the operation locally:

Database connection strings, API tokens, JWTs, and private keys are matched and replaced with typed placeholders: [REDACTED:API_KEY], [REDACTED:DB_URL].
The sanitized context is then supplied to the model, allowing the agent to complete syntax analysis, refactoring, and logic debugging without ever holding live credentials.
Repository include/exclude filters enforce boundary rules, preventing private infrastructure directories or client-specific folders from ever being captured.

Layer 2: Governed Enterprise LLM Gateway (Credential Isolation)

In standard setups, developers store personal or shared organization API keys (OpenAI, Anthropic, Gemini, Azure OpenAI) directly in local .env files or shell environment profiles. This creates widespread credential sprawl and makes revocation difficult.

The ReclaimLLM Enterprise Gateway isolates master credentials entirely:

Central Secret Storage: Provider master credentials reside once in the central enterprise gateway vault. They never touch developer laptops.
Team-Scoped Gateway Keys: Developers and automated CI pipelines receive scoped gateway keys restricted to specific approved models, daily token budgets, and provider endpoints.
Request Attribution: Every outbound prompt is attributed to an organization member, team, project, and interface.

Layer 3: Encrypted Session Storage & Sovereign Residency (Zero-Trust)

Enterprise CISOs require assurance that historical session data cannot become a secondary breach vector.

ReclaimLLM implements a zero-trust storage boundary:

Customer Recovery Keys (AES-256): Raw transcript bodies are encrypted at rest using AES-256 encryption. Administrators download a one-time recovery key during setup that is never stored in plaintext on ReclaimLLM servers.
Searchable Metadata Boundary: Session summaries, token metrics, tool invocation counts, and anomaly indicators remain indexed for governance dashboards without requiring transcript decryption.
Data Residency & VPC Self-Hosting: Regulated teams can mandate US or EU cloud data residency, or deploy ReclaimLLM's server directly inside their private Virtual Private Cloud (VPC) using Docker or Kubernetes Helm charts.

Layer 4: Multi-Cadence Alerting Without Notification Fatigue

Security alerts fail when they trigger notification fatigue.

Autonomous agents are naturally repetitive: they retry broken commands, execute failed test loops, and explore files iteratively. If a security platform sends an email every time an agent touches a file, developers and SecOps teams will filter the notifications to spam within days.

Conversely, relying exclusively on an administrative dashboard means acute credential exposures could sit unreviewed for days.

ReclaimLLM solves this trade-off with a multi-cadence alerting engine:

Immediate Acute Alerts (With Suppression Windows): If detector AD-004 identifies an agent accessing credentials in an unmonitored environment without DLP coverage (was_redacted: false), an immediate notification is dispatched to SecOps and the developer. To prevent agent retry loops from flooding inboxes, repeated triggers enter an automatic 4-hour suppression window unless severity escalates.
08:00 Daily Digests for Routine Touches: Standard file touches where Pre-Execution DLP successfully sanitized credentials (was_redacted: true) are compiled into a scheduled morning digest.
Zero Secrets in Email Payloads (Privacy by Design): External emails pass through third-party mail transit servers. An alert email should never create a secondary data breach. ReclaimLLM email payloads contain strictly allowlisted metadata:

Detector code and severity tier (AD-004: Critical)
Affected session IDs and developer attribution
Matched file category (e.g., env_file, private_key) and access surface (shell_read, code_mention)
Zero prompt text, zero raw source code, and zero credentials.

Every notification includes authenticated deep links directly into the filtered session trace within the secure portal.

The Operational Outcome: Audit-Ready AI Engineering

By deploying an active control plane, engineering organizations achieve three critical operational outcomes:

Continuous Regulatory Compliance: Organizations can prove to SOC 2, ISO 27001, and GDPR auditors that credentials are programmatically scrubbed at the workstation boundary, master keys never touch laptops, and data residency boundaries are strictly enforced.
Deterministic Incident Triage: When unusual activity occurs, SecOps teams do not have to guess what an agent did. They have immutable session traces linking prompt intent, tool execution, and sanitized file changes.
Uninhibited Developer Velocity: Engineers retain the freedom to use modern AI assistants (Claude Code, Cursor, Gemini CLI, local agents) without being constrained by heavy-handed manual approval gates.

Enterprise AI security is not about preventing developers from using autonomous agents. It is about providing the execution guardrails that allow them to build safely.

Originally published at https://reclaimllm.com/blogs/enterprise-ai-coding-security-control-plane

Claude Code security best practices for engineering teams (2026)

Momin Aziz — Sat, 31 Oct 2026 14:13:30 +0000

Originally published on ReclaimLLM: https://reclaimllm.com/blogs/claude-code-security-best-practices

Managed settings, deny rules, sandbox limits, hooks, MCP and transcripts: the Claude Code controls a 10–100 person team should set, and what each misses.

Claude Code security best practices for engineering teams (2026)

Executive summary

Team rollout checklist for Claude Code, layered by control (managed settings → permissions → sandbox → hooks → MCP → transcripts → gateway → audit), each with an honest “what it misses” line.
When the hook runs, recognized .env / *.env access is fail-closed (sanitize Read, block Bash dumps, or deny if the file cannot be inspected). Hook process crashes/timeouts and egress-backend errors can still fail open unless you set Claude’s onFailure: "block".
Claude Code’s local transcript path is ~/.claude/projects/; provider transcripts may still hold unredacted content.
Coverage detection tells you when hooks are missing—it is detection, not MDM.

Securing Claude Code for a team means four layers: managed settings that developers cannot override, permission deny rules and sandboxing for what the agent can touch, hooks that inspect prompts and tool calls, and an audit trail of what was actually read and sent. None of these layers alone covers every path secrets can take. This checklist walks through each control in order, cites Anthropic’s own documentation, and states plainly what each layer misses so you can assign an owner before a customer security review.

For a product-level overview of how ReclaimLLM fits Claude Code, see Claude Code security.

The Claude Code security risks that matter for a team

Claude Code is an agent: it reads files, edits code, runs shell commands, and can call MCP servers without a human approving every step. That maps cleanly to OWASP LLM risks such as sensitive information disclosure (LLM02) and excessive agency (LLM06).

Concrete risks for a 10–100 person engineering team include:

Secrets in prompts, file reads, and tool output. A pasted log line or an accidental .env read can reach the model and land in local session history.
MCP servers and plugins with their own credentials and network access, configured outside your repo review process.
Local transcripts under ~/.claude/projects/ that retain what the agent saw unless you shorten retention or skip history (verify current defaults in Anthropic’s Claude directory docs before you publish internal policy).
Per-developer drift. Individual ~/.claude/settings.json files diverge unless managed settings or MDM enforce a baseline.

Canadian teams may also align rollout with CCCS guidance on generative AI (ITSAP.00.041); the controls below are tool-specific, not a substitute for your own risk assessment.

Layer 1: Managed settings (the only layer developers cannot override)

Anthropic supports org-wide policy through managed-settings.json, MDM-delivered policy, or server-managed settings from the claude.ai admin console. Managed keys take highest precedence over user, project, local, and --settings files. See Settings and Managed settings.

Keys worth setting

Key	Purpose
`allowManagedPermissionRulesOnly`	Managed scope only: ignores allow/ask/deny rules from non-managed settings files
`permissions.disableBypassPermissionsMode`	Blocks bypass-permissions mode (nested under `permissions`, not top-level)
`availableModels`	Locks which models developers can select (merge behavior varies by managed source; see settings reference)

Confirm key names against the current settings reference before you paste them into MDM templates.

What it misses

Managed settings govern Claude Code only. Cursor, Codex, Copilot, or a browser tab on the same laptop are out of scope. You still need a delivery mechanism (MDM or the admin console) and a process to verify machines actually received the file.

Layer 2: Permission rules (deny before allow)

Permissions let you deny specific tools and paths. Deny and ask rules apply immediately; allow rules from a committed project file may wait until the folder is trusted.

Anthropic’s own example includes patterns such as Read(./.env) and Read(./.env.*). That blocks Claude’s Read tool—not every way a secret can leave disk.

What it misses

Shell commands are a different tool. cat .env, grep, or PowerShell equivalents can still print values unless you add sandbox limits, hooks, or operational habits. For a reproducible walkthrough of ignore files versus deny rules versus shell paths, see .claudeignore and .env—this post keeps that story to one paragraph so you can link there for depth.

Layer 3: Sandboxing

Per Anthropic’s sandboxing docs (verified October 2026): the sandbox wraps shell commands. Tools and processes that run outside it include:

Built-in file and web tools (Read, Edit, Write, WebFetch, WebSearch), which follow permission rules instead—a denyRead entry does not stop the Read tool, and allowedDomains does not limit WebFetch the same way.
Other processes Claude Code starts: command hooks, local MCP servers, plugin monitors, LSP servers, and helper commands such as the status line command and apiKeyHelper, which run with full access.

On native Windows, Claude Code runs commands unsandboxed; Anthropic recommends WSL2 for sandboxed shell execution.

What it misses

File tools, MCP, hooks, plugin monitors, LSP servers, and status-line/apiKeyHelper helpers all sit outside the shell sandbox. You need sandbox plus deny rules plus hooks, not “turn on sandbox and stop worrying.”

Layer 4: Hooks for inspection and redaction

Claude Code exposes dozens of hook events (hooks reference); three that matter most for data loss prevention are PreToolUse, UserPromptSubmit, and PostToolUse. Hooks run at the boundary between the agent and your filesystem or network.

How ReclaimLLM uses Claude Code hooks

Env DLP (default on). On PreToolUse, recognized .env and *.env Read calls are redirected to a sanitized temporary copy; Bash-style commands that dump env files are replaced with a block message. If a recognized env source cannot be inspected (unreadable, oversized), the handler raises DLPRedactionError and returns permissionDecision: deny—fail-closed for that class of access when the hook runs.
Egress guard. Before shell execution, the guard blocks common exfiltration paths (for example curl, wget, scp, rsync, nc, and several other binaries and inline fetch patterns) toward non-allowlisted destinations, plus a GeoIP country firewall. Cloud metadata endpoints are rejected server-side even if an org tries to allowlist them.

Local ambient redaction elsewhere in ReclaimLLM is string replacement plus folder exclusion, not semantic classification; direct env-file reads redact every assignment in the sanitized copy.

Honest limits (two different failure modes)

When the hook runs, recognized env-file DLP is fail-closed as described above. That is not the same as “hooks always block every leak.”

When the hook process fails, behavior differs:

Hook crash, removal, or timeout: Claude Code’s default is fail-open unless you set onFailure: "block" (available in Claude Code v2.1.295+). ReclaimLLM’s installer does not set onFailure on injected hooks; teams can add it themselves if they want crash/timeout fail-closed.
Egress guard backend errors: the guard logs and may fail open (allowed=1) on non-2xx responses or timeouts.

That is why coverage detection without MDM exists: ReclaimLLM coverage is detection, not MDM. Pair hooks with alerts when sensitive files are touched (AD-004) and with pre-execution egress controls (egress guard).

Layer 5: MCP servers and plugins

Claude Code stores MCP server configuration in ~/.claude.json. Review entries for hardcoded tokens, keep an approved-server list, and prefer environment variables or helper-based credentials over literals in JSON.

For a cross-tool MCP deep dive, see MCP security for coding agents when published; until then, use the MCP installation hooks announcement as product context.

What it misses

MCP servers run outside the shell sandbox and may not respect the same permission deny rules as built-in Read. Treat each server as its own mini-service with credentials and egress.

Layer 6: Transcripts and retention

Claude Code keeps local session history under ~/.claude/projects/ (also used by ReclaimLLM’s historical sync for backfill). ReclaimLLM-owned local artifacts use owner-only permissions; provider-owned transcript files may still hold unredacted content after a read. See AI coding transcripts as a secret store for retention and purge options.

What it misses

Transcript controls reduce blast radius after a mistake; they do not undo a secret already sent to inference. Combine retention policy with hook redaction and rotation playbooks.

Layer 7: A central gateway for keys and model policy

ReclaimLLM’s enterprise LLM gateway keeps team-scoped keys and provider credentials server-side. The gateway does not see local file reads—it governs API traffic you route through it, not everything Claude Code touches on disk.

What it misses

Developers can still point Claude Code directly at a provider unless you combine gateway policy with routing detection (coverage signals AD-013). Use gateway keys as one layer, not the whole story.

Layer 8: Detection and an audit trail

Even perfect prevention fails sometimes. Plan for evidence:

Sensitive file access alerts (AD-004): P0 email with throttling; zero-exfiltration email bodies (no secret values in mail).
External network egress detector (AD-015): flags anomalous outbound patterns after the fact.
Admin audit log: 365-day retention and CSV export per ReclaimLLM audit log docs.

Privacy controls and US or EU data residency apply to ReclaimLLM-hosted data; ReclaimLLM’s SOC 2 Type II is targeted for early 2027—not certified today.

A 30-minute rollout checklist

Copy this table into your runbook and assign owners before you widen Claude Code to client code.

#	Control	Where	Owner
1	Managed settings deployed	MDM / claude.ai console	IT
2	.env / key deny rules	managed settings	Security
3	Sandbox on (macOS / Linux / WSL)	managed settings	Security
4	Hooks installed + coverage alerting	Developer machines	Platform
5	MCP allowlist reviewed	~/.claude.json / plugins	Platform
6	Transcript retention policy set	Claude settings + docs	Security
7	Gateway keys per team	Gateway admin	Platform
8	Alerts routed to an owner	Email / SIEM	Security
9	Quarterly access review	Dashboard / audit export	CTO

Install hooks with native hooks documentation and verify the Coverage tab after the first wave of installs.

Is Claude Code safe for enterprise use?

Claude Code can be run safely for many enterprises when you treat it like any other privileged developer tool: managed baseline, deny rules for secret paths, sandbox where supported, hooks at the tool boundary, MCP hygiene, transcript policy, and detection you can show auditors. Anthropic documents the knobs; your security team owns how strictly they are set and verified.

No vendor—including Anthropic or ReclaimLLM—can guarantee zero disclosure if developers paste live secrets into prompts. The goal is defense in depth with measurable coverage, not a single checkbox.

Next step: See which Claude Code sessions touched secrets—start free. For a live walkthrough, book a 20-minute rollout review.

FAQ

Is Claude Code safe for enterprise use?

It can be, with managed settings, permission denies, sandboxing (on supported platforms), hooks, MCP review, transcript policy, and audit evidence. Safety depends on configuration and monitoring, not the product name alone.

What are the main Claude Code security risks?

Uncontrolled file and shell access, secrets in prompts and transcripts, MCP credentials, and inconsistent per-developer settings. Agent behavior aligns with OWASP LLM02 and LLM06 if left unmanaged.

Can developers override Claude Code managed settings?

No for keys delivered through managed settings, MDM, or the admin console—those take highest precedence. User and project files cannot weaken managed deny rules when allowManagedPermissionRulesOnly is enabled.

Does the Claude Code sandbox stop the agent reading `.env`?

The sandbox wraps shell commands, not built-in Read/Edit/Write. Use permission deny rules and hook DLP for file tools; do not rely on sandbox alone.

Do Claude Code hooks block every leak?

No. Recognized .env reads are sanitized or denied when the hook runs. Hook process crash, timeout, or egress-backend errors can still fail open unless you configure Claude’s onFailure: "block" and monitor coverage.

Where does Claude Code store conversation history?

Local project history under ~/.claude/projects/. Treat those JSONL files as sensitive; align retention with your data classification policy and verify current Anthropic defaults in official docs before audit season.

Originally published at https://reclaimllm.com/blogs/claude-code-security-best-practices

DEV Community: Momin Aziz

Government of Canada IT Jobs in Ottawa

What counts as a Government of Canada IT job

IT-01 to IT-05: what each level actually does

Current IT pay, by level

The eight IT work streams

Who can apply

Language requirements

Security screening

Where to find Government of Canada IT jobs in Ottawa

How the application actually works

Tailoring your résumé to essential qualifications

Student and early-career routes

FAQ

Tech Jobs in Ottawa: Who's Hiring

Ottawa's tech market, in one paragraph

Kanata North and the rest of the city

Who's hiring: tech jobs in Ottawa right now

Public sector vs. private sector

Security clearance and controlled goods

Pay transparency in Ontario postings (2026)

Where to search for tech jobs in Ottawa

How to get noticed

Early-career routes

FAQ

IT-02 Jobs: Pay and How to Qualify

What IT-02 means

IT-02 pay

IT-02 vs IT-01 vs IT-03

What IT-02 work looks like by stream

Education and experience on real IT-02 posters

Education (the group minimum)

Experience (what changes from poster to poster)

How to show IT-02-level experience on a résumé

FAQ

Antigravity and Codex security: stopping secret leaks with hooks and sandboxes

Antigravity and Codex security: stopping secret leaks with hooks and sandboxes

Executive summary

Three ways coding agents leak secrets (read, print, send)

Antigravity security

Gemini CLI → Antigravity CLI (agy)

Hooks

Terminal sandbox

MCP tokens

Transcripts

Known exfiltration research

Codex security

Hooks

Sandbox and approvals

Transcripts

Antigravity vs Codex: hooks and sandboxes

How ReclaimLLM fits Antigravity and Codex

Two different “fail” modes (do not conflate them)

Checklist for Antigravity and Codex

FAQ

Is Google Antigravity secure for company code?

Is Gemini CLI still available?

Do Antigravity hooks fail open?

Can Codex hooks block a command?

Where are Antigravity MCP OAuth tokens stored?

Does ReclaimLLM’s AD-015 cover Antigravity?

OpenTelemetry is the right interface for LLM APIs — but not for coding agents

OpenTelemetry is the right interface for LLM APIs — but not for coding agents

Use OpenTelemetry Where the Application Owns the Call

Coding Agents Expose a Different Surface

One Downstream Model, Explicit Provenance

What Teams Should Deploy

Why .cursorignore is not DLP

Why .cursorignore is not DLP

What .cursorignore actually does

Terminal bypass and agent file reads

Privacy Mode is not redaction

What hook DLP does instead

Bottom line

Prevent API keys and .env from reaching ChatGPT, Cursor, and Claude Code

Prevent API keys and .env from reaching ChatGPT, Cursor, and Claude Code

Where secrets enter the model context

What does not solve it alone

Hook DLP: redact at the tool boundary

After capture: review and sensitive handling

Gemini CLI → Antigravity CLI (`agy`)

Does the Claude Code sandbox stop the agent reading `.env`?