docs: add a security posture & liability disclaimer

officeParser is a parser/generator/converter that necessarily opens
files from potentially untrusted sources, so it's worth stating plainly
what that means for consumers of the library:

- README.md: new "Security & Trust Boundary" section (linked from the
  TOC) covering what's actively hardened against (injection, zip bombs,
  DoS, SSRF - see CHANGELOG.md for the ongoing history) and the honest
  limit of that: no software is guaranteed vulnerability-free, there's
  no dedicated security team behind a solo-maintained project, and
  final responsibility for a compromised input file's impact rests with
  the consumer, per the MIT LICENSE's "AS IS" clause.
- SECURITY.md: a matching "Security Posture & Disclaimer" section
  between "My Security Commitment" and "Out of Scope" - the more
  canonical version of the same statement for the doc people land on
  specifically for security questions. Also fixed two stray "us"/"our"
  instances to "me"/"my" for pronoun consistency with the rest of the
  file (this is a solo-maintained project, first person throughout).

Author: harshankur

README.md

@@ -62,6 +62,7 @@ A robust, strictly-typed **Node.js and Browser** library for parsing office file
 - [Browser Usage](#browser-usage)
 - [Troubleshooting & Common Issues](#troubleshooting--common-issues)
 - [Known Limitations](#known-limitations)
+- [Security & Trust Boundary](#security--trust-boundary)
 - [Contributing](#contributing)
 
 ---
@@ -1231,6 +1232,28 @@ For a full debugging guide, visit the [Live Documentation](https://harshankur.gi
 
 ---
 
+## Security & Trust Boundary
+
+`officeParser` is a **parser, generator, and converter** — by design, it opens and processes files
+handed to it, which may originate from an untrusted source (a user upload, an inbox attachment, a
+scraped document, etc.). I treat every input as potentially adversarial and actively harden the
+library against it: output sanitization against injection (HTML/CSS/URL/script/CSV/RTF/Markdown),
+zip-bomb protection, resource/recursion limits against denial-of-service payloads, SSRF protection
+during PDF rendering, and more — see [CHANGELOG.md](CHANGELOG.md) for the ongoing history of these
+fixes and [SECURITY.md](SECURITY.md) for how to report a vulnerability.
+
+That said: **no parser can be guaranteed 100% free of vulnerabilities**, and I'm the sole
+maintainer of this project — there is no dedicated security team behind it. I'm committed to
+fixing legitimate reports promptly, but I cannot promise the library is impervious to a
+sufficiently novel attack, and I make no warranty to that effect (see the [LICENSE](LICENSE)'s
+"AS IS" clause, under which this software is provided). **Responsibility for how a compromised or
+malicious input file affects your system ultimately rests with you, the consumer of the library**
+— if you process files from untrusted sources, apply the isolation appropriate to your threat
+model regardless (sandboxing/containerization, resource limits, running as a low-privilege
+process, etc.) rather than treating any single library's hardening as a complete solution.
+
+---
+
 **npm**: [https://npmjs.com/package/officeparser](https://npmjs.com/package/officeparser)
 
 **github**: [https://github.com/harshankur/officeParser](https://github.com/harshankur/officeParser)

SECURITY.md

@@ -17,9 +17,9 @@ Maintenance and security patches are currently provided for the latest major bra
 **Please do not open public issues for security vulnerabilities.**
 
 ### 🛑 Why Private Disclosure?
-Publicly disclosing a vulnerability before a fix is available creates an immediate window for attackers to exploit the issue against the millions of users currently running this library. Private reporting allows us to develop, test, and release a patch **before** the technical details are shared, ensuring that the community remains protected.
+Publicly disclosing a vulnerability before a fix is available creates an immediate window for attackers to exploit the issue against the millions of users currently running this library. Private reporting allows me to develop, test, and release a patch **before** the technical details are shared, ensuring that the community remains protected.
 
-To facilitate a safe disclosure, please use our private GitHub reporting channel:
+To facilitate a safe disclosure, please use my private GitHub reporting channel:
 
 ### GitHub Private Reporting
 1.  Navigate to the [Security tab](https://github.com/harshankur/officeParser/security) of this repository.
@@ -37,6 +37,26 @@ Upon receiving a valid report, I will:
 
 I ask that you follow **coordinated disclosure** practices and allow a reasonable window to release a patch before sharing technical details publicly.
 
+## Security Posture & Disclaimer
+
+`officeParser` is a parser, generator, and converter for office documents — it is often used to
+process files from untrusted sources (user uploads, email attachments, scraped content, etc.), so
+I treat every input as potentially adversarial. I actively invest in hardening the library against
+malicious input — output sanitization against injection, zip-bomb and decompression limits,
+recursion/resource limits against denial-of-service payloads, SSRF protection during PDF
+rendering, and more — and I will keep shipping security fixes for as long as I actively maintain
+this project (see CHANGELOG.md for the ongoing history).
+
+That said, I am the sole maintainer of this project, with no dedicated security team behind it,
+and **no software can be guaranteed free of vulnerabilities**. I make no warranty that
+`officeParser` is or will remain impervious to a sufficiently novel attack — the library is
+provided "AS IS", without warranty of any kind, per the [LICENSE](LICENSE). **Final responsibility
+for the impact of a compromised or malicious input file on your system rests with you, the
+consumer of the library.** If you process files from untrusted sources, apply isolation
+appropriate to your own threat model (sandboxing/containerization, resource limits, a
+low-privilege execution context, etc.) rather than relying on any single library's hardening as a
+complete solution.
+
 ## Out of Scope
 - **Third-Party Dependencies**: Vulnerabilities in upstream libraries (e.g., `tesseract.js`, `pdfjs-dist`, `fflate`) should be reported directly to their respective maintainers.
 - **Semantic Chunking & External APIs**: When using `Semantic Strategy` for chunking, you provide an `embed` function. If this function sends data to external LLM providers (like OpenAI or Anthropic), the security and privacy of that data transfer are governed by your implementation and the provider's terms. `officeParser` itself does not transmit document data to external servers by default.