AI tools for security work: IDE, browser and CLI plug-ins, chatbots, assistants and MCP servers

Why this matters

Up to this point the course has treated AI as the thing being secured. From here it is also the thing doing some of the securing, and that changes the question you ask about it. A model inside your security team's tooling reads your code, your logs, your tickets and sometimes your credentials. It is, whatever the vendor calls it, a privileged user that takes instructions from text.

That matters because the tools arrive from the bottom up. An analyst installs a browser extension that summarises threat reports. A developer turns on a code assistant in their editor. Someone connects a chatbot to the ticketing system "just to draft replies". Each choice is small and each is reasonable, and together they give a set of models read access to most of what the organisation would least like to leak, with no inventory and no review.

The practitioner's job in this lesson is twofold: to use these tools well, because they genuinely speed up security work, and to recognise where each one sits, what it can reach and what happens when the text it reads was written by an attacker. Scenario questions on this objective usually describe a task and a tool, and ask either which tool fits or what is wrong with how it was deployed.

The lesson

Where AI tools sit in a security team's day: the IDE, the browser and the command line

Think of the tool categories by where they run and what they can see, because that decides both their usefulness and their risk.

IDE plug-ins. A code assistant inside the integrated development environment sees the open file, usually the surrounding project, and often the terminal output. For security work it explains unfamiliar code, suggests fixes for findings a scanner raised, writes unit tests for an input validator and drafts detection rules or scripts. Its context is the repository, which means it may also see whatever secrets were committed to that repository, and its suggestions land directly in code that will be built and shipped. Lesson 22 covers reviewing what it writes.

Browser plug-ins. An extension that can read the page you are on. Useful for summarising a long advisory, translating a foreign-language forum post during an investigation, or explaining an unfamiliar web console. The risk is breadth: an extension with permission to read every page reads your webmail, your cloud console and your HR system too, and it reads hostile pages with the same trust as friendly ones. A web page is untrusted input, so a browser assistant is the textbook carrier for indirect prompt injection, covered in lesson 17.

CLI plug-ins. An assistant in the terminal that turns a plain-language request into a command, explains an error or, in agentic forms, runs commands itself. For an analyst it shortens the gap between "I need every failed login from that host in the last hour" and the query that answers it. It also runs with the operator's shell privileges, so a suggested command that deletes, exfiltrates or changes permissions is one keystroke from execution. The control is the same as for any generated code: read it before it runs, and do not grant an assistant unattended execution on a privileged host.

The pattern across all three: the closer a tool sits to execution, the more a wrong or manipulated output costs.

Chatbots and personal assistants, and what they must not be given

A chatbot is a conversational interface to a model, either a public service or an internal one built by the organisation. A personal assistant is a chatbot given standing access to a person's own data and accounts: mailbox, calendar, documents, sometimes the ability to send and schedule on their behalf.

The useful work is real. A chatbot drafts an incident communication, explains a log format, turns a policy into a checklist or answers "what does this PowerShell do?". A personal assistant can triage a security manager's inbox or summarise the week's change requests.

What they must not be given is decided by data classification and agency, not by convenience:

• Regulated or confidential data in a public chatbot. Pasting a customer database extract, source code under licence restrictions or an unredacted incident timeline into a consumer service sends it to a third party under that service's terms. The fix is an approved enterprise service with contractual retention and training terms, plus redaction before submission (lesson 14).
• Standing credentials. An assistant should act through delegated, scoped, revocable access, never through a password or long-lived key pasted into its configuration.
• Unreviewed authority to act. Reading the inbox and drafting replies is one level of risk; sending mail, accepting meetings or forwarding documents on the user's behalf is another. The more an assistant can do without a human confirming, the more a single injected instruction in an incoming email can do. This is excessive agency, LLM06 in the 2025 OWASP list (lesson 7), and approval design is the subject of lesson 26.

A useful exam heuristic: when a scenario's assistant both reads untrusted content and can take an outward action, that combination is the finding.

The Model Context Protocol: what an MCP server exposes to a model

The Model Context Protocol (MCP) is an open protocol, introduced by Anthropic in November 2024, through which an AI application connects to external tools and data in a standard way. Before it, every assistant needed its own bespoke integration for each system; MCP gives one interface that any compatible application can use.

The roles are simple. An MCP client, inside the AI application, connects to one or more MCP servers. Each server exposes three kinds of thing:

• Tools: actions the model can ask to invoke, such as "search tickets", "query the SIEM", "create a firewall change request".
• Resources: data the application can read into the model's context, such as files, records or documents.
• Prompts: reusable prompt templates the server offers for common tasks.

A server can run locally on the user's machine or be reached remotely over the network. Either way, the security-relevant fact is that an MCP server is a privileged integration. Whatever credentials it holds to the ticketing system or the SIEM, the model can exercise through it, steered by whatever text is in its context.

Three consequences follow, and each maps onto an attack from Domain 2:

• The server's scope is the blast radius. A server that holds an administrator token exposes administrator actions. Scope its credentials to the narrowest role the use case needs, which is least privilege applied to a non-human identity (lesson 12).
• Tool descriptions and returned data are model input. A malicious or compromised server can carry instructions in its tool descriptions or in the data it returns, and the model may follow them. Treat a third-party server as untrusted code and untrusted content at once.
• Servers are supply chain. Installing a community MCP server is installing software that will run with your access. It belongs in the same dependency and provenance review as any library (lesson 18).

The design point worth remembering: MCP standardises the connection, and for remote servers how a client obtains an access token, but not the authorisation policy. Deciding which user may invoke which tool, and which actions need a human to confirm, remains the deploying organisation's job.

Vetting an AI tool before it touches code, tickets or credentials

Before an AI tool is approved, answer the same questions a security review asks of any third-party integration, plus a few that are specific to models.

Data flow. Where do prompts, context and outputs go? Are they retained, and for how long? Are they used to train the vendor's models, and can that be switched off contractually rather than by a setting a user can change? Which jurisdiction processes them?

Permissions. What does the plug-in or server request, and is that proportionate? A summarising extension that asks to read all sites, or an MCP server that asks for write access to a ticketing system it only needs to search, fails here.

Identity and credentials. Does it use single sign-on and delegated, scoped tokens that can be revoked centrally? Or does it want a stored key?

Agency. Can it act without confirmation? Which actions, and can those be restricted to read-only or gated behind approval?

Provenance. Who publishes it, is it signed, and how are updates delivered? Extensions and community servers have been a supply-chain route in ordinary software for years, and an AI tool with broad access is a more valuable target.

Observability. Are its prompts, tool calls and outputs logged somewhere the security team can see, with sensitive values sanitised (lesson 15)?

The outcome is an approved tool list with stated permitted uses, which is also the practical answer to shadow AI (lesson 31): people use unapproved tools when there is no approved one that does the job.

Choosing the right tool for a task a scenario describes

Scenario questions tend to give a task and ask which tool fits. The reasoning runs from the task's context and its consequence:

Two traps recur. The first is choosing the most capable tool when a narrower one fits: an agent with shell and email access is not the right answer to "summarise this report". The second is treating the tool as the control. An AI tool that finds vulnerabilities, writes rules or triages alerts speeds up a process; the human review, the approval and the logging are what make the process trustworthy.

What the exam is really asking

When the question names a tool, ask three things: what can it see, what can it do, and who reviews its output before that output matters. A wrong answer usually gives the tool more of one of those than the task needs.