Secure Context

Last updated: Sep 9, 2026

Fluid Attacks' Secure Context feature sends security rules to your AI coding agent. The agent applies these rules to the new code that it writes. Secure Context is preventive: it guides new code before a vulnerability exists. The feature runs on the Fluid Attacks MCP server. It works in your IDE and in your CLI.

Below is a simple explanation of how Secure Context works and how to use it.

How Secure Context works

Secure Context runs as a tool on the Fluid Attacks MCP server. Your AI agent calls this tool during a coding session.

The tool returns a rule block. The block contains two kinds of rules:

• Generic rules: a fixed, curated set from Fluid Attacks. Every developer receives the same generic rules.
• Contextual rules: rules that Fluid Attacks selects from the security requirements that your group does not meet. These rules change from one group to another.

Fluid Attacks finds the group that owns the repository from the repository URL. The feature maps the repository to its registered root. It then maps that root to its group. You do not select the group by hand.

The agent loads the rule block into the session. The rules guide the code that the agent writes next. The block looks like this:

[Fluid Attacks Secure Context]
4 rules loaded from Fluid Attacks · fluidattacks.com

- CWE-284. Improper access control — Enforce access controls on trusted server-side points, never the client.
- CWE-311. Missing encryption of sensitive data — Encrypt all stored sensitive information with vetted mechanisms.
- CWE-89. SQL injection — Use parameterized queries or stored procedures for dynamic SQL.
- CWE-502. Deserialization of untrusted data — Do not deserialize untrusted data before integrity checks.

When your group has contextual rules, the block adds one more line before the rule list, such as (3 contextual for group your-group · 1 default).

For the full list of MCP tools, including get_secure_context_rules, see capabilities and use cases.

Use Secure Context

As a prerequisite, you must connect the Fluid Attacks MCP server in your MCP client, such as Cursor or Claude Code.

You also need one of these roles on the group: Customer Manager, Group Manager, User, or Vulnerability Manager.

With the MCP server connected, follow these steps:

1. Open your AI coding agent in the repository that you work on.
2. Ask the agent to load the Fluid Attacks Secure Context rules. Some agents call the tool on their own, without a prompt. The agent sends the repository URL and the branch.
3. Read the rule block that the agent shows. The tool response starts with an instruction for the agent. The rule block that follows starts with the line [Fluid Attacks Secure Context].
4. Continue to write code with the agent. The agent applies the rules to the new code.

As a result, your agent writes new code with the security rules of the group that owns the repository.

Scope and limits

Read the limits below before you use the feature.

Secure Context does the following:

• It loads security rules into the agent at the start of the session.
• It guides the new code that the agent writes from that point on.
• It serves generic rules to every repository.
• It serves contextual rules to a registered repository.

Secure Context does not do the following:

• It does not scan your code.
• It does not evaluate existing code, diffs, files, or functions.
• It does not block your commits or your CI pipeline.
• It does not send your source code to Fluid Attacks.

The feature also has these special cases:

• If the repository is not registered in Fluid Attacks, the agent receives the generic rules only.
• If you do not have an authorized role on the group, Secure Context returns a "not authorized" message and no rules.
• Contextual rules never contain client names, file paths, or repository names. The only input from your group is which security requirements the group does not meet.