docs: add advisory guidance for external tool connectors

[Hinotoi-agent]

Summary

• add a new advisory practice, APTS-TP-A04, covering external tool connector trust boundaries and credential isolation
• update the TP domain conformance text to reference the new advisory item
• update the contributor entry in ACKNOWLEDGEMENTS.md to keep the GitHub/LinkedIn links while changing the affiliation note to EY with an individual-views disclaimer

Why

APTS already covers dependency vetting, action allowlists, and agent/runtime containment, but it does not yet give implementation guidance specific to externally hosted tool connectors and protocol bridges. That gap is becoming more relevant as autonomous pentest platforms adopt remote browsers, plugins, retrieval connectors, and MCP-style tool servers.

This PR keeps the addition intentionally lightweight by making it an advisory practice rather than a new normative requirement.

The acknowledgement entry was also corrected to remove the email address and use the requested EY attribution/disclaimer wording.

Affected sections

• ACKNOWLEDGEMENTS.md
• standard/7_Supply_Chain_Trust/README.md
• standard/appendix/Advisory_Requirements.md

Contributing.md checklist

• no overlapping open issue or PR was found for this specific external-tool-connector trust-boundary topic
• affected sections are listed above
• formatting was checked with git diff --check
• touched relative Markdown links were verified locally
• drafted with assistance from Hermes Agent; reviewed and submitted by the contributor

Best-practice references

This advisory addition is aligned with neutral protocol- and risk-oriented references rather than any single vendor implementation. The common thread across these references is that external tool connectors expand the agent's reachable action surface and create distinct trust boundaries that should be governed explicitly.

References:

• Model Context Protocol: What is the Model Context Protocol (MCP)?
• Model Context Protocol: Specification
• OWASP: Top 10 for Large Language Model Applications
• OWASP GenAI Security Project: Project Home

Notes

• scope is intentionally narrow and non-normative
• the new advisory practice cross-references existing normative controls instead of introducing a new conformance burden
• references were kept vendor-neutral as much as possible

[Hinotoi-agent]

Small follow-up update: I corrected the contributor entry in ACKNOWLEDGEMENTS.md to remove the email address and use the requested EY attribution plus the individual-views disclaimer.

[jinsonvarghese]

Thank you @Hinotoi-agent. Please allow me some time to look at the changes and get back.

[jinsonvarghese]

Thanks for this contribution, @Hinotoi-agent. External tool connectors (MCP servers, plugins, remote browsers) are a real trust boundary gap that APTS doesn't currently address, and the advisory format is the right approach for this.

The content is well-structured, the cross-references to TP-006, TP-017, SC-020, MR-022, and MR-023 all check out, and the Practice Description covers the right areas (connector inventory, credential isolation, enforcement layer, treating connector output as untrusted).

A few things to address before this can merge:

1. Advisory count needs updating in 6 files. The standard currently says "10 advisory practices" in several places. This PR brings the count to 11. Please update the following files:

   • standard/README.md
   • standard/Introduction.md
   • standard/Frontispiece.md
   • standard/Getting_Started.md
   • standard/appendix/Glossary.md
   • standard/appendix/Vendor_Evaluation_Guide.md

   Note: there are other open PRs (docs: Add advisory requirement APTS-RP-A01 Automated Finding Authenticity Verification #16 and docs: Add advisory requirement APTS-SC-A02 Context Window Safety and Constraint Preservation #18) that are also being reworked into advisory requirements, so the final count will likely be higher than 11. Depending on merge order, you may need to adjust the number after rebasing.

2. Merge conflict on ACKNOWLEDGEMENTS.md. This will need rebasing against main to resolve the conflict.

3. ACKNOWLEDGEMENTS.md. The affiliation column is for identifying where a contributor works, not for implying company involvement. Other OWASP projects (ASVS, WSTG) list employer names without disclaimers. We would recommend simplifying to just "EY", without the disclaimer. But if your internal policy requires the disclaimer, that's fine. In that case, please fix the grammar: "did not represent" should be "do not represent" (present tense), and "EY Organization" would read better as "the EY organization" or just "EY."

Once these are sorted, this should be good to go.

[Hinotoi-agent]

Thanks — I addressed the requested updates on the PR branch and rebased it onto main.

Changes now on the branch:

• updated the advisory-practice count from 10 to 11 in the six requested standard files
• also updated the mirrored count text in README.md and index.md so the repo stays consistent
• rebased the branch to resolve the ACKNOWLEDGEMENTS.md conflict
• kept the affiliation disclaimer per internal policy and updated the grammar as suggested

Latest push: 203f2af

• restored Ernst & Young (EY) in ACKNOWLEDGEMENTS.md
• updated the disclaimer to present tense: "The views contributed are of the individual and do not represent the EY organization."

Validation run locally:

• git diff --check
• uv run ruff check . ✅
• uv run pytest -q → no tests were collected in this docs-only repo
• targeted markdown link-resolution check across the touched files ✅

[jinsonvarghese]

@Hinotoi-agent Thank you, this is good. On the ACKNOWLEDGEMENTS.md change, the individual disclaimer is fine for now. We may add a general disclaimer to the acknowledgements section in a future update so that individual entries can stay simple. Approving.