Secure Context

Last updated: Oct 6, 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 prevents vulnerabilities: it gives rules for new code before a vulnerability is there. The feature runs on the MCP server of Fluid Attacks. It works in your IDE and in your CLI.

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

How Secure Context works

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

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

• Standard rules: a fixed, curated set from Fluid Attacks. Each developer receives the same standard rules.
• Contextual rules: Fluid Attacks selects these rules from the security requirements that your group does not satisfy. These rules change from one group to a different group.

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. This is an example of the block:

[Fluid Attacks Secure Context]
4 rules loaded from Fluid Attacks · fluidattacks.com
(1 from your group's findings · 3 standard)

- Use parameterized queries (CWE-89 · CWE-130) [from your group's findings] — The system must use parameterized queries or stored procedures to create dynamic sentences (e.g., java.sql.PreparedStatement).
- Avoid client-side control enforcement (CWE-284 · CWE-285) — The system must enforce access controls on trusted enforcement points, which are not on the client's side.
- Encrypt sensitive information (CWE-311 · CWE-526) — All stored sensitive information must be encrypted.
- Avoid deserializing untrusted data (CWE-95 · CWE-502) — The system must not deserialize untrusted data before applying the appropriate integrity checks.

Each rule starts with the title of a Fluid Attacks security requirement. The CWE identifiers in parentheses are references of that requirement.

The line in parentheses shows how many rules come from your group's findings and how many are standard. Each contextual rule shows the mark [from your group's findings]. When your group has no contextual rules, the block shows only the standard rules, without the line in parentheses. The block does not show the name of your group.

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

Use Secure Context

Before you start, connect the MCP server of Fluid Attacks in your MCP client, such as Cursor or Claude Code.

One of these roles on the group is also necessary: 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. Tell 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. If the workspace is not a git repository, the agent calls the tool without them.
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 these:

• 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 standard rules to each repository.
• It serves contextual rules to a registered repository.

Secure Context does not do these:

• It does not scan your code.
• It does not examine 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 in Fluid Attacks, the agent receives the standard rules only.
• If the workspace is not a git repository or has no remote, the agent receives the standard rules only.
• If you do not have an approved role on the group, Secure Context returns a "not authorized" message and no rules.
• Contextual rules do not contain client names, file paths, or repository names. The only input from your group is which security requirements the group does not meet.