OpenContext sits between an LLM host (Claude.ai, Claude Desktop, any MCP client) and a public open data portal. Data flows in two directions, and each direction has its own threat model.

The model constructs queries (SQL, SoQL, ODSQL, ArcGIS where clauses) and IDs that the connector forwards to the portal. Defenses:

• Query validators (core/query_validator.py, plugins/*/…_validator.py) reject multi-statement, write, and dangerous-function queries and cap query length.
• Identifier whitelists restrict field names, metric expressions, ORDER BY, and HAVING values assembled by aggregate_data. For ArcGIS, order_by accepts only field names with an optional ASC/DESC (WhereValidator.validate_order_by); aggregate_data statistic fields, output names and group_by fields must be plain identifiers that exist in the layer's schema, and having goes through the same WhereValidator as where. layer must be an integer id the service lists. All of these are checked before any request is sent.
• build_where_clause escapes values and rejects non-identifier field names.
• Redirect credential scoping (_create_http_client(protect_headers=…)) follows redirects (so a renamed portal domain such as data.sfgov.org → data.sf.gov keeps working) but strips the credential header (Socrata X-App-Token, CKAN/ODS/ArcGIS Authorization) on any hop whose host is not the configured portal/base host (or a trusted extra such as *.arcgis.com). A lapsed domain can be re-registered by someone else, so the credential is never forwarded to it; the request still follows through, unauthenticated.
• ArcGIS SSRF guard (_validate_feature_url, trusted_service_hosts, auto_trust_hub_services) stops a dataset record from steering Feature Service requests to arbitrary hosts. *.arcgis.com, the portal host and the explicit allow-list are always trusted. Hub-referenced hosts are auto-trusted only for https URLs on public DNS names with an ArcGIS REST service path; IP literals (e.g. cloud metadata endpoints), single-label and .internal/.local names, and non-service paths are refused, the bearer token is never forwarded to an auto-trusted host (redirect credential scoping applies), and operators can disable auto-trust.

Everything a portal returns is untrusted text that lands inside the model's context window: dataset titles and descriptions, schema labels, error bodies, and—most importantly—the records themselves. Datasets such as 311 requests, permit applications, and public comments contain free text submitted by members of the public. An attacker does not need to compromise the portal to plant text in it; they file a service request.

Because hosts commonly pair an OpenContext connector with tools that can act (email, calendar, files), the realistic harm is not a wrong answer about parking tickets but a poisoned record instructing the assistant to exfiltrate or modify the user's data through another connector.

All of this lives in core/portal_content.py and is applied centrally by BaseOpenDataPlugin, so every plugin gets it without opting in.

None of this makes injection impossible. The model ultimately decides what to do with the text, and the host's own defenses—tool permission prompts, the client's injection classifiers, and the user reviewing actions—are the last line of defense. The connector's job is to shrink the attack surface, keep its own voice separable from portal content, and give operators visibility.

• Do not wire OpenContext into unattended agent pipelines that also hold write-capable tools (email, file sharing, payments).
• Watch for Possible prompt injection markers warnings in CloudWatch; each carries the tool name and matched heuristics.
• Keep trusted_service_hosts (ArcGIS) minimal.
• When adding a plugin, build output through portal_line / portal_text / safe_id / format_records and put next-step hints in ToolHandler(guidance=…), not in the data body. Set id_pattern and provider_label on the plugin class.

Report vulnerabilities privately to the repository maintainers rather than opening a public issue.