Documents You Will Hear About in Implementations

In real projects, teams and consultants often talk about a set of artefacts. Names vary, but you will regularly see something like the following:

• AI risk register (or AI-specific risk treatment records linked to the main risk process)
• AI model register (inventory of models and AI systems in scope)
• Stakeholder impact assessments (how AI use affects interested parties)
• AI policy and ethical guidelines (direction and rules from leadership)
• Audit logs for AI decisions (traceability of automated or AI-assisted decisions, where applicable)
• Data provenance logs (where training or operational data came from and how it is governed)
• AI-specific incident handling procedures (what to do when something goes wrong)
• Continual improvement records (actions from monitoring, audits, management review)

This list is useful as a checklist of conversation topics. It is not a list copied from ISO as “these eight forms with these exact titles.” Treat it as what many organisations end up needing to satisfy requirements and operate safely, not as a standard-mandated table of contents.

The Key Idea: Requirements, Not Templates

ISO/IEC 42001 states requirements (what the management system must achieve). It does not ship spreadsheets, clause-by-clause forms, or mandatory column headers. The implementer (with the organisation) designs how documented information looks: one workbook, a tool, a wiki, or an integrated GRC platform. What must hold is that you can demonstrate conformity: roles, risks, controls, monitoring, and improvement are real, owned, and traceable.

If someone sells “the ISO 42001 template pack,” they are selling their way of meeting requirements. It may be good or average. It is not “the ISO format,” because ISO does not define that level of format for most topics.

What Is Explicit, What Is Implied, What Is Best Practice

Explicit (in the standard): Clauses refer to documented information where the organisation must maintain or retain specific types of information (for example, scope, policies, objectives, evidence of competence, operational planning and control, results of monitoring and measurement, internal audit and management review records, nonconformity and corrective action). The standard uses defined terms; your training or a good clause-by-clause guide maps each to what must exist as documented information, not to a single global template.

Implied: If you say you control AI system lifecycle or risk, an auditor will expect records that show it happened: approvals, changes, assessments, not only a policy PDF that nobody follows.

Industry best practice: Registers, structured impact assessments, decision logs, and clear incident playbooks reduce operational risk and make audits smoother. They are not all named in one numbered list in 42001 the way consultants list them, but they are how mature teams implement the requirements.

If You Are Preparing for Lead Implementer Certification

Do you need to memorise templates? No. Exams focus on requirements, process, and how documented information supports the AIMS, not on reproducing a vendor’s register layout.

What does “designing documents” mean? It means: given Clause X, you can state what information must be captured, who owns it, how often it is updated, and how it links to risk, objectives, and operation. “Design” is about content and control, not font and logo.

How deep does the exam go? Typically to the level of knowing which areas need documented information, why, and how that ties to leadership, planning, operation, and improvement. Not to filling in every cell of a sample risk register from memory.

Different Consultants, Different Folder Structures

Where flexibility exists: Format, tool, naming, number of documents (you may merge or split, as long as control and traceability remain clear). One organisation’s “AI model register” may be a tab in a larger asset system; another may use a dedicated database.

Where requirements are non-negotiable in spirit (even if the shape varies): You must be able to show risk identification and treatment linked to AI systems and context; accountability and roles; operational control of AI activities in scope; monitoring and measurement; evidence of performance, audit, and management review; and continual improvement when things fail or drift. If an auditor cannot follow the thread from risk to control to evidence, the style of the document will not save you.

Example: AI Risk Register (Logical Shape, Not a Mandatory Form)

Purpose: To record AI-related risks (safety, bias, security, privacy, reliability, legal, reputational, etc.) in scope, align them to owners and treatments, and support review and reporting.

Key fields (illustrative): Risk description; AI system or process reference; cause and consequences; existing controls; treatment (accept, mitigate, transfer, avoid); owner; target date; residual risk; link to incidents or changes when relevant.

Lifecycle use: Created and updated during planning and change; referenced in operation when systems change; reviewed after incidents or monitoring signals; inputs to management review and improvement.

The standard does not say “column 7 must be residual risk.” It says the organisation must address risks and opportunities in a way that the management system can plan, implement, and check. A register is one practical way to do that; the logic matters more than the layout.

What ISO Is Really Asking

ISO is not a documentation beauty contest. It is about showing that risks are identified, controls and responsibilities are in place, performance is monitored, and the system improves when gaps appear. Documents and records are vehicles for that proof. If they are thin, duplicated without control, or disconnected from real operation, the organisation has a problem regardless of how polished the cover page is.

Takeaways

1. Separate the standard from the template shop. ISO/IEC 42001 specifies requirements and documented information obligations; it does not prescribe universal forms for registers and logs.

2. Use common artefact lists as maps, not as law. They help you brainstorm what to build; they do not replace clause-by-clause understanding.

3. For certification exams and serious implementation, focus on traceability: what must be documented, who owns it, and how evidence shows the AIMS is operating.

4. Invest effort in design, not in copying layouts. One well-linked risk and control story beats ten decorative PDFs that teams do not use.

One side effect of AI that we do not talk about enough is this, the emotional relationship people have with code.

For many of us, programming was never just about output.

There was a quiet satisfaction in typing every statement ourselves. Watching logic unfold line by line.

Back then there was no autocomplete. No AI suggestions. Often no mouse-heavy IDE workflow. Just a keyboard, a blinking cursor, and patience.

You typed everything. You fixed everything. You understood everything.

There was joy in seeing printf print exactly what you expected. In zeroing a register with xor eax, eax. In tightening a loop like while(index).

One piece of code that programmers have often held up as beautiful is the fast inverse square root from Quake III Arena: a tiny, hardware-aware hack that does one Newton–Raphson iteration after a magic constant to approximate 1/√x without a proper square root. It is the kind of craft that comes from knowing the machine.

float Q_rsqrt(float number)
{
  long i;
  float x2, y;
  const float threehalfs = 1.5F;
  x2 = number * 0.5F;
  y  = number;
  i  = * ( long * ) &y;
  i  = 0x5f3759df - ( i >> 1 );
  y  = * ( float * ) &i;
  y  = y * ( threehalfs - ( x2 * y * y ) );
  return y;
}

Take Rust. Why do people love enums in Rust? Because they make invalid states unrepresentable. You do not have “maybe null” scattered everywhere; you have Option<T>. You do not hide errors in a magic value; you have Result<T, E>. The type system encodes the shape of your logic, and pattern matching forces you to handle every case. It is a different kind of craft: not bit-twiddling, but the pleasure of the compiler and the data structure in one.

enum Message {
    Quit,
    Move { x: i32, y: i32 },
    Write(String),
}

fn handle(msg: Message) {
    match msg {
        Message::Quit => { /* ... */ }
        Message::Move { x, y } => { /* ... */ }
        Message::Write(s) => { /* ... */ }
    }
}

It was not just about shipping software. It was craft.

I remember attending ILUGC meetups in early 2000 at IIT Madras. People gathered to talk about Linux, kernels, patches, open-source. I would walk up to strangers asking how they got their modem working on Debian 3.1. That is where I first heard serious discussions about FreeBSD and OpenBSD.

There were similar communities around the world, Chaos Computer Club, BSD user groups, Linux User Groups everywhere. Pure meetups of craft work. No branding. No hype. Just people obsessed with understanding systems.

This was also the era of 5.25-inch floppy disks, thin magnetic media inside soft sleeves. 360 KB or 1.2 MB felt sufficient. Many systems had no hard disks. There was no internet. No Windows. Just MS-DOS 4.01, a blinking A:\ prompt, and whatever tools fit on a floppy.

Abstraction was thin. You could almost see the hardware through the code.

Now AI-assisted tools generate much of that surface layer.

Syntax appears instantly. Boilerplate disappears. Patterns complete before you finish thinking.

Productivity increases. And that is a good thing.

But I sometimes think about what changes in our relationship with code when we stop typing the details ourselves.

Maybe the craft does not disappear. Maybe it moves upward, from writing syntax to designing systems.

I know this may not matter from a productivity standpoint, but there was something meaningful about typing every line ourselves.

If you have read “The Story of Mel” you may understand the kind of craft I am referring to. It was never really about assembly code. It was about intimacy with the machine.

The Story of Mel Summarized by AI

“The Story of Mel,” written by Ed Nather, describes a remarkable programmer named Mel who worked on the early LGP-30 in the late 1950s. The machine used a rotating drum for memory, so accessing instructions depended on the physical timing of the drum. Mel understood this timing so deeply that he wrote assembly programs arranged precisely to match the drum’s rotation. Instead of using conventional jumps, he positioned instructions so that when one finished executing, the next one would appear under the read head at exactly the right moment. His programs even used self-modifying code to adjust instruction addresses dynamically. Other programmers tried to rewrite his work in a cleaner, more understandable way, but their versions ran slower than Mel’s original code. What made Mel’s work extraordinary was that his code was not just logical; it was synchronized with the physical behavior of the hardware. The story shows a programmer who treated the machine almost like a mechanical instrument. It illustrates a time when deep knowledge of hardware and software together defined programming skill. Even today, the story is remembered as a symbol of craftsmanship and intimacy with the machine.

A deterministic application can become an AI-enabled system through very small code changes. Sometimes as little as 50 lines that introduce a model call can transform a traditional application into one whose behaviour is influenced by AI; content, recommendations, or decisions then depend on the model. That shift creates a major governance challenge: the same system that was “just an application” is now in scope for ISO/IEC 42001 and must be identified, documented, and managed. This article is for cybersecurity leaders, AI governance professionals, architects, auditors, and implementers. It explains why identifying AI systems is harder than it sounds, what auditors are up against, and how implementers can build governance that makes AI usage visible and governable. This article focuses on identifying and inventorying AI systems and on governance practices that support that. It does not cover the full set of ISO/IEC 42001 requirements (e.g. lifecycle, risk treatment, documented information, or management review). The working definition of “AI system” used here is practical; for the formal definition, see the standard or ISO/IEC 22989.

1. The Small Change That Changes Everything

From a governance perspective, what matters is not how many lines of code an application has, but whether its behaviour is influenced by an AI model. A large, rule-based system remains deterministic. A small change that adds a single model call can make the same system non-deterministic and subject to AI governance. That shift is often invisible at the process or documentation level; only code and integration points reveal it.

Consider a support ticket router. Originally it might classify tickets using fixed rules: keyword matching, category lookup tables, and priority thresholds. The behaviour is predictable; the system is not an AI system. A product team then adds a call to an external API that uses a language model to suggest category and priority. A developer adds a small module: an HTTP client, a prompt, and a call to the model API. The change may be a few dozen lines. Functionally, the system is now “smarter”; from a governance standpoint, it is now an AI system.

The following illustrates the kind of change that turns a deterministic path into an AI-influenced one. First, a purely rule-based classification:

def classify_ticket(subject: str, body: str) -> dict:
    # Deterministic: rules only
    if "billing" in subject.lower() or "invoice" in body.lower():
        return {"category": "billing", "priority": "high"}
    if "login" in subject.lower():
        return {"category": "access", "priority": "medium"}
    return {"category": "general", "priority": "low"}

After the change, the same function delegates to a model for edge cases. The surface area of the change is small; the governance impact is large.

def classify_ticket(subject: str, body: str) -> dict:
    # Try rules first
    if "billing" in subject.lower() or "invoice" in body.lower():
        return {"category": "billing", "priority": "high"}
    if "login" in subject.lower():
        return {"category": "access", "priority": "medium"}
    # AI-influenced path: model call
    response = model_client.complete(
        prompt=f"Classify support ticket. Subject: {subject}. Body: {body[:500]}.",
        max_tokens=50
    )
    return parse_model_response(response)  # category, priority from model

The application is now subject to AI governance: model behaviour affects decisions, and the organisation must identify, document, and manage it under ISO/IEC 42001.

2. Why This Creates an AI Governance Problem

Once the model is in the path, the system’s outputs depend on the model’s behaviour. That behaviour can change with model updates, prompt changes, or input distribution shift. The organisation needs to treat it as an AI system: inventory it, assess risk, define policies, and maintain documentation. If the change was never flagged to compliance or architecture, the system will not appear in the AI inventory. Auditors cannot validate what is not identified; implementers cannot govern what they do not know exists. ISO/IEC 42001 is not only about auditing AI systems; it is about building management processes that make AI usage visible and governable. Without a deliberate process, small, incremental additions of AI create invisible governance gaps.

3. Why Identifying AI Systems Is Harder Than Traditional Asset Identification

Many organisations already maintain an asset register. In frameworks such as ISO/IEC 27001, the focus is on information assets within the scope of the ISMS: applications, infrastructure, data, and often people or roles. You list them, classify them, assign ownership, and link them to risks and controls. The unit of account is the asset itself (e.g. “Support Ticket System,” “CRM”).

ISO/IEC 42001 asks for something different: an inventory of AI systems. The unit of account is not “any asset” but “a system in which AI influences decisions or outcomes.” The same application may appear in both registers; in 42001 it is in scope only if and where AI is used. So 42001 requires an extra dimension: not just “what systems we have,” but “where AI is used inside them.” A 27001 asset register rarely captures that; it does not usually tag “contains model call” or “AI in decision path.” AI may be introduced via third-party APIs, SaaS features, or internal microservices, with no central list of “AI projects.” The inventory has to be discovered, not simply read from an existing register. Relying on the 27001 register alone is therefore insufficient for 42001.

4. Auditor Perspective: The Visibility and Inventory Challenge

Auditors must validate that the organisation has identified its AI systems in scope. That means assessing whether the discovery process is repeatable, documented, and sufficient to support the stated scope. If the organisation has not looked in the right places (e.g. codebases, API integrations, vendor capabilities), the auditor cannot rely on the inventory. The challenge is to design procedures that catch systems like the ticket router above: small changes with large governance implications. AI often appears at integration points (calls to model APIs, embeddings, SaaS ML features) or in internal services that are not named or documented as “AI.” Auditors should check that the organisation has a defined process for discovering and maintaining the AI system inventory, that the process was applied consistently, and that the resulting scope is plausible given the organisation’s size, industry, and use of technology. The objective is to gain confidence that the inventory is a reasonable basis for the AI management system, not that every possible AI use has been found. Perfect visibility is unrealistic; a repeatable discovery process and evidence that it is followed are what auditors should validate.

5. Auditor Risk: When Hidden AI Systems Undermine the Audit

A change in an application that turns it into an AI system (e.g. a few dozen lines adding a model call) is exactly the kind of change that creates auditor risk. The auditor is asked to form an opinion on whether the organisation’s AI management system is adequate: whether AI systems are identified, risks are assessed, and controls are in place. If the organisation (or the auditor) does not account for the fact that small, local code or integration changes can turn a previously deterministic system into an AI system, the scope of the management system can be materially understated. Systems that should be in the inventory are missing; risks attached to those systems are not assessed; the auditor may be validating a picture that is incomplete. That gap is auditor risk: the risk that the audit conclusion is based on an inventory or scope that omits AI systems that fall within the intended scope of the management system. Auditors therefore need to understand this dynamic and to design procedures that address it (e.g. sampling codebases or integration points, challenging the discovery process, and assessing whether the organisation has considered “small change” scenarios). Acknowledging that a small change can create a large governance shift is part of assessing and mitigating auditor risk.

6. Implementor Perspective: How to Build Governance Around This Reality

Implementers face the same reality from the inside: they must set up AI governance so that the organisation can identify, document, and manage AI systems even when those systems emerge from small code changes. That starts with defining what qualifies as an AI system. A practical definition is: a system in which an AI model (internal or external) influences content, recommendations, or decisions that affect the organisation or its stakeholders. Rule-based logic alone does not qualify; once a model call influences the outcome, the system is in scope. With that definition in place, the implementer establishes an AI system inventory as the single source of truth: system name, purpose, where AI is used (e.g. classification, recommendation, generation), how it is implemented (internal model, external API, SaaS feature), and ownership. The inventory should be linked to architecture and risk assessments so it drives the rest of the management system. AI review should be integrated into architecture review and change management: when new services, integrations, or features are proposed, there is a checkpoint to ask whether AI is involved and whether the system belongs in the inventory. Awareness training is important: developers and product teams need to know that introducing a model API or an AI-backed SaaS feature triggers governance steps. Some organisations add AI governance office hours or quick security review paths so that teams can get fast, lightweight approvals for low-risk AI use without blocking delivery. Without awareness and accessible approval paths, AI will continue to appear in production without being captured in the inventory.

7. Governance Checkpoints and Approval Workflow

To prevent AI from being introduced without oversight, organisations should define clear checkpoints. Before a new external AI service or model integration goes into production, it should go through an approval process: who is allowed to sign off, what information must be documented (vendor, data flows, purpose, risk level), and how the system is added to the AI system inventory. The same applies to internal model deployments or material changes to existing AI use (e.g. prompt changes, model upgrades). Checkpoints can be embedded in architecture review boards, change advisory boards, or a dedicated AI governance review. The goal is not to block innovation but to ensure that every AI system is known, scoped, and managed.

Shadow AI: A Consequence of Weak Governance and Missing Checkpoints

When there are no clear approval steps or when developers are unaware that AI use triggers governance, “Shadow AI” appears: AI usage that is not in the inventory, not approved, and not subject to the organisation’s policies or risk controls. Examples include teams subscribing to external model APIs on a credit card, embedding SaaS features that use ML without checking data or compliance implications, or adding a small model call in a legacy application without telling anyone. Shadow AI is not necessarily malicious; it is often the result of speed and lack of awareness. The consequence is the same: the organisation cannot govern what it does not know about. Strong checkpoints and approval workflows, combined with discovery (see below), reduce Shadow AI by making AI use visible and expected to be registered.

8. Discovery Methods to Uncover Hidden or Unapproved AI Usage

Technical discovery complements governance checkpoints by finding AI that was introduced without going through them. Implementers and auditors can use a combination of methods:

• Code scanning for AI SDKs: Scan codebases for imports or dependencies that indicate model usage (e.g. OpenAI client libraries, Hugging Face, LangChain, vendor SDKs). Search for prompt construction, completion calls, and embedding APIs.
• Dependency analysis: Review dependency lists (e.g. package.json, requirements.txt, go.mod, Cargo.toml and Rust crates) for ML/AI libraries and API clients. Flag new or updated dependencies that suggest AI integration.
• API integration review: Identify outbound calls to model APIs, embeddings APIs, or vendor endpoints that document AI features. Use API inventories, network egress reviews, or integration documentation.
• Infrastructure and service usage monitoring: Review usage of internal ML platforms, model serving endpoints, or shared AI services. Monitor which applications or teams consume these services.
• Vendor and SaaS capability review: Periodically check whether purchased applications or platforms have introduced or expanded AI features (e.g. suggested replies, content moderation, summarisation) that process organisational data.

Architecture review and developer or product team interviews remain important: trace data flows, ask where classification, recommendation, or generation is performed, and which products call external AI services. Discovery should be repeatable and documented so that auditors can assess whether it was applied consistently.

9. Building and Maintaining the AI System Inventory

The AI system inventory is the central artefact. It should record, for each AI system: name, purpose, where AI is used (e.g. classification, recommendation, generation), how it is implemented (internal model, external API, SaaS feature), ownership, and linkage to risk assessment and controls. The inventory should be updated when new AI features are deployed, when integrations change, or when discovery finds previously unknown usage. It should be owned by a function that can enforce the process (e.g. AI governance, architecture, or risk). Linking the inventory to architecture and change management ensures that new systems are added at the right time and that the inventory stays actionable for the rest of the management system.

Some organisations go further with structures that, while not strictly required by ISO/IEC 42001, support consistent and governable AI use. An approved AI register (or approved AI services list) works like an approved list of base images (e.g. approved Docker or Linux images): only listed models, APIs, or vendors are permitted for production use unless an exception is documented. That makes discovery and policy enforcement easier. Where prompts drive material decisions, a prompt registry can be required: a central place to store, version, and review prompts used in production so that changes are visible and auditable. A centralised LLM orchestration layer is another option: all LLM calls are routed through one gateway or proxy. That gives a single point for logging, policy enforcement, and visibility into which applications use which models; it also simplifies discovery because outbound model traffic is concentrated in one place. These practices are organisational choices that complement the AI system inventory and make governance more tractable at scale.

10. Why Continuous Discovery Matters

Enterprises will never have perfect, real-time visibility into every line of code or every API call. New integrations and features are added continuously; 50 lines of code can turn an application into an AI system at any time. So discovery cannot be a one-off. It should be periodic (e.g. quarterly or as part of architecture or risk cycles) and triggered by significant events (e.g. new vendor onboarding, major releases, or post-incident reviews). The aim is not perfection but a repeatable, risk-based process that keeps the inventory accurate enough to support risk management and compliance. Continuous discovery, combined with governance checkpoints and developer awareness, is what makes AI usage visible and governable over time.

11. Conclusion: AI Governance Begins the Moment AI Influences System Behaviour

A deterministic application that gains a model call becomes an AI system under ISO/IEC 42001. The governance impact is large even when the code change is small. Identifying such systems is harder than traditional asset identification because 42001 requires knowing not only what systems exist but where AI is used inside them. Auditors validate that the organisation has a repeatable discovery process and a plausible inventory; implementers build that process by defining what counts as an AI system, establishing the inventory, introducing governance checkpoints and approval workflows, integrating AI review into architecture and change management, training developers, and applying technical discovery methods. Shadow AI is the consequence of weak governance and missing checkpoints; reducing it depends on making AI use visible and expected to be registered. ISO/IEC 42001 is not just about auditing AI systems; it is about building management processes that make AI usage visible and governable. AI governance begins the moment AI influences system behaviour, regardless of how many lines of code it took to get there.

What the Work Typically Looks Like

A typical engagement runs through the stages below. Each one is less like a movie and more like careful, repeatable project work.

Speak to Customers and Understand the Scope

In the movies, someone hands you a target and says “get in.” In reality, you spend a lot of time on calls and in meetings. You need to understand what is in scope (which systems, which types of tests, which environments) and what is explicitly off limits. You need to know what “success” means for the client: is it a compliance checkbox, a pre-go-live check, or a deep security review? Scope creep and scope fights are common; unclear scope leads to rework, disputes, or both. As a lead, you treat this phase as the foundation. Get it wrong here and the rest of the engagement is built on sand.

Read the Requirement, Make a Proposal, Interpret It Clearly

You will read statements of work, RFPs, and requirement documents. You will draft or contribute to proposals: what you will do, how long it will take, what you will deliver, and what you will not do. This is not glamorous; it is paperwork and interpretation. But clarity here avoids pain later. Clients often use vague language (“test our infrastructure,” “external penetration test”). You have to turn that into a concrete plan: which IP ranges, which application scope, black box or grey box, whether social engineering or physical testing is included. If you do not nail this down, you will either under-deliver in the client’s eyes or over-deliver and burn out. Neither is good.

Talk to Stakeholders and Understand the Targets

You work with internal project managers, client IT teams, and sometimes compliance or risk owners. You need to understand the environment: what systems exist, how they are used, what is critical, and what is legacy. You need to know the boundaries: which networks you can touch, which credentials you will get (if any), and what hours or windows you have for testing. Again, this is communication and coordination, not keyboard wizardry. Stakeholders may not understand the difference between a vuln scan and a pen test; you explain, you align, and you document what was agreed. This phase sets the stage for the actual testing so that when you run your tools, you are testing the right things in the right way.

Run the Scans, Probes, and Exploits; Most of Them Fail

This is the part that looks most like “hacking,” and it is still nothing like the movies. You run scanners, run manual probes, and try exploits. Most attempts do not land. Systems are patched, configurations are locked down, or the vulnerability you thought was there is not exploitable in this environment. You are not “getting in” every time; you are methodically testing and documenting what works and what does not. You track everything: what you ran, when, and what the result was. The job is as much about ruling out risks as it is about finding them. If you go in expecting to crack every engagement in an hour, you will be frustrated. If you go in expecting a mix of findings, dead ends, and careful note-taking, you will be prepared.

Create Screenshots, Collect Logs, and Gather Proof

Evidence matters. Every finding that goes into the report needs to be provable. You spend a lot of time capturing screenshots, saving command output, saving logs, and organizing proof for every vulnerability. This is meticulous work. You label files, you note timestamps, and you make sure a reader can follow your steps and reproduce the issue. In the movies, the hacker moves on to the next target. In reality, you stop, document, and then move on. Poor evidence means findings get challenged, clients lose trust, or the report is unusable for remediation. Treat evidence collection as a core part of the job, not an afterthought.

Prepare the Report

Report writing is a large part of the job. You write executive summaries for people who will never read the full report. You list vulnerabilities with clear titles, descriptions, severity, and impact. You suggest mitigation strategies and recommendations. You make sure the language is consistent, the severity ratings are justified, and the report is actionable. This is not a one-page “we found some stuff” note; it is a deliverable that the client will use for compliance, for remediation planning, and for internal communication. Many technically strong testers struggle here because they prefer running tools to writing. If you want to lead engagements or be taken seriously, you need to be able to write clearly and structure a report that stands up to scrutiny.

Have a Closure Call With the Customer

When the report is done, you do not just send it and disappear. You have a closure call (or several) with the customer. You walk stakeholders through the findings, explain severity and impact in plain language, and go through mitigation steps. You answer questions: Why is this critical? What do we do first? Can you help us understand this? Some clients are technical; many are not. Your job is to make sure they understand what was found and what to do next. This is again communication and empathy, not hacking. How you present the results often matters as much as the results themselves. A poorly delivered message can cause panic or dismissal; a clear, calm delivery helps the client act.

Sometimes Re-Test After the Customer Patches

After the client remediates, they often want you to run another round of tests to verify that the issues are fixed. You re-run the relevant checks, confirm that the vulnerability is no longer present (or is adequately mitigated), and document the outcome. Then you update the report or issue a short closure note. This is not a full new engagement; it is verification. But it is part of the lifecycle. Some engagements have two or three rounds of test, report, fix, re-test. You need to be comfortable with that rhythm and keep your evidence and documentation consistent so that “we fixed it” can be backed up by your retest results.

Move On to the Next Project

When the engagement is closed, you move on to the next one. Rinse and repeat. You might be on multiple engagements in parallel: one in scoping, one in testing, one in reporting. You switch context, you keep your notes organized, and you do it again. There is no single “big score”; there is a pipeline of projects, each with the same phases. The excitement is not in the drama of one hack; it is in getting good at the full cycle and in the moments when your work actually helps a client improve their security.

It’s Not Like the Labs

None of this looks much like what you learned from CTF challenges, from platforms like Hack The Box or TryHackMe, or from “black screen, green matrix” ideas of hacking. Those are great for building skills: understanding vulnerabilities, using tools, and thinking like an attacker. But the day job is different. It is scoped, documented, and repeatable. It is meetings, reports, and evidence. It is often boring in the sense of being routine and process-driven.

If you go in expecting only technical thrills, you will be disappointed. If you go in knowing that the job is as much about communication, documentation, and consistency as it is about finding flaws, you will have a better start. Penetration testing is boring; that is the job. The excitement is in getting good at it and in the moments when your understanding and discipline actually help a client improve their security.

Where the Real Opportunity Lies

The pull of the job is real. Few roles put you in front of production systems with permission to break them. You probe, you test, and in scoped engagements you exploit or take down live infrastructure; with a contract and rules, not a hoodie in a basement. Along the way you pick up what most developers never see: hardware quirks, low-level code, OS internals, bypass techniques. There is real responsibility, real thrill, and real hardcore knowledge here; it just does not look the way you imagined.

ProbeScout: What We Are Building and Why

I am building an agentic vulnerability assessment and discovery system (ProbeScout) that ties together concurrent scanning, traffic shaping, and an AI layer for risk and prioritization. The pipeline uses nmap for port scanning and service discovery, traceroute and tcptraceroute for target intel and path analysis, and tools like hping3 for SYN probes, with results fed into an AI layer for reasoning about findings.

The system is designed to operate autonomously with minimal human intervention, scaling to thousands of IP addresses via continuous, batch, or scheduled execution. The goal is to reduce reliance on manual effort for probe orchestration, result analysis, and prioritization decisions.

To get there, the orchestration layer must plan campaigns, decompose work into batches or phases, keep context under control when scan output is large, and delegate analysis without overloading a single prompt. That is exactly the kind of workload agent frameworks target: multi-step tasks, tool use, and structured execution. Below we look at CrewAI and Deep Agents and where they fit in a setup like ProbeScout.

Where the Agent Layer Runs

ProbeScout runs as three tiers:

• Frontend (Node.js): Create campaigns, upload targets, initiate scans, monitor runs. Talks to the backend for orchestration and live status.
• Backend (Python): Orchestration, scheduling, coordination. Assigns work to Rust scanning agents, receives status and progress updates, aggregates results, and drives reasoning or prioritization. This is where CrewAI or Deep Agents run.- Scanning agents (Rust): Run on separate machines in the network. Perform probing (nmap, traceroute, tcptraceroute, etc.), coordinate with the backend, and report status, progress, and results.

The backend uses tools to dispatch work to Rust agents (e.g. “run nmap on this target”, “run traceroute”, “store result in X”) and to push status and results to the frontend.

CrewAI

CrewAI lets you define agents with roles and goals and crews that work together on tasks. In a system like ProbeScout, you can assign different agents to different stages in the Python backend: one agent for target selection or campaign planning, one for dispatching work to Rust agents and collecting progress, one for result analysis and prioritization. Tasks can be chained and delegated, which fits a pipeline where the frontend creates a campaign, the backend decomposes it and hands batches to Rust agents, and results flow back for analysis and display. Useful when you want a clear separation of roles and a crew that collaborates on a shared goal.

LangChain Deep Agents

Deep Agents (from the LangChain ecosystem) are built for complex, multi-step tasks with built-in support for:

• Planning and task decomposition – e.g. break a campaign into batches or phases and track progress as Rust agents report back.
• Context management – file system tools (read_file, write_file, etc.) so the backend can offload scan results and logs instead of blowing the context window.
• Subagent spawning – delegate a subtask (e.g. “analyze this subnet’s results” or “correlate these ports”) to a dedicated agent and keep the main orchestrator’s context focused.
• Pluggable backends – in-memory, local disk, or durable stores for state and context, so the backend can scale and persist across restarts.
• Long-term memory – persist facts or preferences across runs for a more consistent scanning and prioritization strategy.

The Deep Agents SDK is a standalone library on top of LangChain and uses LangGraph for execution, streaming, and human-in-the-loop. In ProbeScout, running in the Python backend, it would coordinate with Rust scanning agents via your existing APIs, aggregate status and results, and drive what the frontend shows and what work gets sent next.

How It Fits Today

In the current setup, the Node.js frontend is where operators create campaigns, upload targets, and initiate scans. The Python backend runs the orchestration and reasoning; that is where you integrate CrewAI or Deep Agents. They call into your Rust agents (via the same coordination channel you already use for status, progress, and results), handle planning and decomposition, and use file system or backend storage to keep scan output and state manageable. Rust agents stay focused on probing; the backend stays focused on what to run and what it means. Either framework fits this split.

Summary

CrewAI gives you role-based agents and crews in the Python backend for collaborative planning, dispatch, and analysis. Deep Agents give you planning, decomposition, context management, subagents, and pluggable backends in one stack, also in the backend. In a system like ProbeScout, both coordinate with Rust scanning agents on separate machines and with the Node.js frontend that creates campaigns, uploads targets, and initiates scans. The architecture stays: Node.js frontend, Python backend (with CrewAI or Deep Agents), Rust scanning agents; the agent layer is the brain in the middle.

A Practical Scenario

Suppose you are building an agentic discovery system inside an enterprise network. The system continuously scans and enumerates thousands of internal systems, collects service details, tracks configuration changes, compares historical states, and feeds that data into an AI layer that reasons about risk or prioritization.

The challenge is not just inference.

You need to handle thousands of concurrent network operations, continuous scheduling, data parsing, state comparison, queue management, and long-running reliability. The system must run 24/7 without leaking memory, collapsing under load, or creating unpredictable latency spikes.

Where Rust Fits

Rust gives you high-performance networking, controlled concurrency through async runtimes like Tokio, and compile-time guarantees that eliminate many common memory and race-condition problems. When you are managing thousands of parallel tasks (scanning, parsing responses, diffing results, feeding pipelines), those guarantees become extremely valuable.

Another advantage is predictability. Systems that continuously process large streams of data cannot afford garbage-collection pauses or silent memory growth. For example, imagine processing vulnerability data across thousands of systems, correlating scan results, tracking changes, and feeding prioritization pipelines. Rust’s ownership model keeps resource usage explicit and stable even in long-running workloads like these.

In architectures like these, the AI model is just one component. Around it sits a large amount of infrastructure: discovery workers, schedulers, enrichment pipelines, storage layers, and APIs that expose results to analysts or other systems.

Example: Concurrent Port Scanning with hping3

A typical backend component runs many scans concurrently but shapes traffic so the network and target are not overwhelmed. Below, we run hping3 for SYN port scanning with bounded concurrency and send results into a channel for downstream processing (e.g. enrichment or an AI risk layer):

use tokio::process::Command;
use tokio::sync::{mpsc, Semaphore};
use std::sync::Arc;

struct ScanResult {
    target: String,
    port: u16,
    open: bool,
}

async fn run_hping3_scan(
    target: &str,
    port: u16,
) -> std::io::Result<ScanResult> {
    let out = Command::new("hping3")
        .arg("-S")
        .arg("-p")
        .arg(port.to_string())
        .arg("-c")
        .arg("1")
        .arg(target)
        .output()
        .await?;
    let open = out.status.success();
    Ok(ScanResult {
        target: target.into(),
        port,
        open,
    })
}

async fn run_concurrent_scans(
    tx: mpsc::Sender<ScanResult>,
    targets: Vec<String>,
    ports: Vec<u16>,
    max_concurrent: usize,
) -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    let sem = Arc::new(Semaphore::new(max_concurrent));
    let mut handles = Vec::new();
    for target in &targets {
        for &port in &ports {
            let tx = tx.clone();
            let permit = sem.clone().acquire_owned().await?;
            let target = target.clone();
            handles.push(tokio::spawn(async move {
                let _permit = permit;
                let result = run_hping3_scan(&target, port).await?;
                let _ = tx.send(result).await;
                Ok::<_, Box<dyn std::error::Error + Send + Sync>>(
                    (),
                )
            }));
        }
    }
    for h in handles {
        let _ = h.await;
    }
    Ok(())
}

Here, packet shaping is done by limiting concurrency with a Semaphore (e.g. max_concurrent: 50) so you do not flood the network or trigger rate limits. The channel tx feeds scan results to another task that can aggregate, store, or pass them to an AI pipeline.

Agentic Vulnerability Assessment and Discovery

I am building an agentic vulnerability assessment and discovery system that ties together concurrent scanning, traffic shaping, and an AI layer for risk and prioritization. The pipeline uses nmap for port scanning and service discovery, traceroute and tcptraceroute for target intel and path analysis, and tools like hping3 for SYN probes, with results fed into an AI layer for reasoning about findings.

The system is designed to operate autonomously with minimal human intervention, scaling to thousands of IP addresses via continuous, batch, or scheduled execution. The goal is to reduce reliance on manual effort for probe orchestration, result analysis, and prioritization decisions.

Architecture

The system is three tiers: Node.js frontend, Python backend, and Rust scanning agents.

• Frontend (Node.js): Create campaigns, upload targets, initiate scans, and monitor runs. The UI talks to the backend for orchestration and live status.
• Backend (Python): Orchestration, scheduling, and coordination. It hands work to scanning agents, receives status and progress updates, aggregates results, and drives reasoning or prioritization. Single control plane for the whole system.
• Scanning agents (Rust): Run on separate machines inside the network. Each agent performs the actual probing (nmap, traceroute, tcptraceroute, etc.), coordinates with the backend over the network, and reports status, progress, and results. Rust keeps scanning fast and predictable; the backend and frontend handle workflow and UX.

Agents register or poll the backend for work, stream progress and results back, and scale out by adding more machines. The frontend is where operators create campaigns, upload targets, and initiate scans.

Useful Cargo Crates for AI Backends

These crates are commonly used when building Rust backends that sit alongside AI inference or orchestration:

Example Cargo.toml for a minimal AI-facing backend:

[package]
name = "ai-backend"
version = "0.1.0"
edition = "2021"

[dependencies]
tokio = { version = "1", features = ["full"] }
axum = "0.7"
serde = { version = "1", features = ["derive"] }
serde_json = "1"
reqwest = { version = "0.11", default-features = false, features = ["json"] }
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter"] }

AI Backend Services That Use Rust

Several production AI backends and infra projects rely on Rust for speed and reliability:

• Candle (Hugging Face): ML inference engine in Rust. Used to run models (including LLMs) with minimal dependencies and good performance on CPU and GPU.
• llm.rs / llama.cpp bindings: Rust crates and tooling around fast inference runtimes, often used for local or edge deployment.
• Inference servers and gateways: Many custom inference gateways that sit in front of Python model servers are written in Rust for request routing, batching, rate limiting, and auth.
• Vector DBs and embedding pipelines: Services that index embeddings, run similarity search, or build RAG pipelines often use Rust for the hot path (e.g. qdrant, milvus-related components, or custom indexers).
• Orchestration and agents: Backends that schedule tasks, call multiple models, or run agent loops use Rust for the control plane and Python (or FFI) for the model calls.
• Observability and telemetry: Pipelines that ingest traces, metrics, or logs from AI workloads sometimes use Rust for high-throughput ingestion and aggregation.

These are examples of the split you see in practice: Python for model code and experimentation, Rust for the services that serve, scale, and orchestrate it.

Python and Rust Together

The Python ecosystem remains central to AI development. Most model libraries, research tooling, and experimentation frameworks still live there. Python remains excellent for experimentation and model development.

In practice, many architectures benefit from both: Python for model development and Rust for the high-performance backend infrastructure around it.

When you need speed, safety, and concurrency in the always-on backend that powers AI systems, Rust becomes a very compelling choice.

Macro Payloads and Initial Attack Chains

Crafting macro payloads for documents as part of an initial attack chain is one practical area. Instead of manually building VBA structures, adjusting execution flow, or refining trigger logic, AI can help generate clean macro templates quickly. You still control the logic, execution path, and safety boundaries. It accelerates development, but does not replace understanding of how Office, process spawning, and detection controls work.

Thick Clients and Binary Triage

Red teaming thick client applications is another strong area. Binary triage is as well. When you load a binary into Ghidra, the first level of understanding takes time. If you extract specific functions and ask a model to summarize control flow, trace user-controlled inputs, or point out unsafe memory handling, it can speed up the early analysis. You still verify everything yourself. You still confirm exploitability. But you understand the code faster.

Lateral Movement Analysis

Lateral movement analysis in a Windows domain becomes complex when the environment is large. Local admin memberships, delegation settings, active sessions, trust relationships. It is not easy to mentally connect all of this. You can feed structured data into a model and take MITRE ATT&CK as a reference to construct possible movement paths across techniques and trust boundaries. It can highlight privilege chains and cross-tier access routes. You then validate what is actually possible and in scope.

C2 and Lab Setup

Making simple C2 implants in lab environments is another example. Instead of manually wiring Sliver profiles, writing custom stagers, tweaking compile flags, and setting up a quick control panel, AI can help generate a basic structure faster. It reduces setup effort. GhostLink is a C&C platform for red team engagements in this space: AI can help with boilerplate, config generation, and wiring up observers or control panels so you spend more time on operator workflow and OPSEC and less on repetitive setup. But OPSEC awareness, detection impact, and responsible usage remain with the operator.

Editing remote process file on the host where the C2 agent runs.

Launching actions from the control panel: download file, upload file, take screenshot on the machine where the C2 agent runs.

Compiling and building agents or implants for different architectures and OS platforms.

Observability and debugging for the C2 platform.

Caution and Guardrails

One caution. This is not about blindly copy-pasting into ChatGPT or casually using AI assistants. You must understand what you are doing. In red teaming, data sensitivity and client trust matter. I clearly advise a few conditions. Prefer local models wherever possible. Use synthetic or sanitized data for experiments. Put proper guardrails in place. Build a small observability layer to log prompts and outputs. And if the customer already has approved AI models in their own cloud environment, it is better to use their endpoints within their boundary instead of moving data outside.

The Real Advantage

AI does not replace red team skill. It reduces time spent on repetitive work and early analysis. The real advantage still belongs to people who understand authentication flows, privilege boundaries, operating system behavior, and trust relationships.

If you know what you are doing, AI makes you faster. If you do not, it only makes you confident without depth.