Docs: Add SAP HANA Cloud Knowledge graph engine documentation

[yonarw]

Description:
Adds a documentation with examples for the usage of langchain with langchain-hana and the SAP HANA Cloud Knowledge graph engine.

Issue:
None - integration documentation

Dependencies:
None

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
langchain	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 28, 2025 1:04pm

[yonarw]

@eyurtsev or @ccurme could I kindly ask for feedback/review to this PR?

[eyurtsev]

Is there any form of query sanization?

This looks like it's allowing for arbitrary queries against the database?

https://langchain-git-fork-yonarw-saphanakg-langchain.vercel.app/docs/integrations/graphs/sap_hana_graph_sparql/#executing-sparql-queries

[yonarw]

It only allows queries against the knowledge graph as the query function calls a stored procedure on our plugin side.
See SPARQL_EXECUTE

[eyurtsev]

Is there a need to sanitize the query? Can a malicious actor inject sql?

[yonarw]

Your concerns are right in a way, it would be possible to pass malicious sparql here in theory. But since you need a dedicated HANA connection to open your HanaRdfGraph handel in the first place, we think langchain-hana shoudn't be responsible for sanitizing in this case. If you already have a connection to HANA, you already can execute sql, sparql however you want and however your connection lets you do it.

[eyurtsev]

The risk profile is developers use langchain-hana package to develop an application and expose some functionality (e.g., question answering) via an endpoint. Most developers will not expect that the Q&A chain can execute privileged commands.

---

Is an attack possible through this code path:

# Create a SPARQL QA Chain
chain = HanaSparqlQAChain.from_llm(
    llm=llm,
    verbose=True,
    allow_dangerous_requests=True,
    graph=graph,
)
output = chain.invoke("which actors acted in Blade Runner?")

print(output["result"])

For example, could a malicious user trick the underlying LLM to drop the database?

If so, this is not a safe implementation since it's:

1. It's surprising to a developer
2. It's not documented as such