docs: Explain the agent tool boundary in common.ai security docs

[kaxil]

The common.ai Security guide opens straight into the per-toolset "Defense Layers" table without first stating the boundary everything else rests on: an LLM agent can only act through the tools you register on it, and cannot run arbitrary code or read the environment, filesystem, or other connections unless a registered tool exposes that. This adds that framing up front and clarifies what "untrusted" applies to.

What changed

• New "What the agent can and cannot reach" subsection before the defense-layers table. It states that the model's reach equals the set of tools you register; that the DAG file is author-written and trusted like any other DAG, while the model's output (its tool-call requests and generated text) is the untrusted part, confined to the registered tools and bounded by the tool-call budget; and that every tool widens the blast radius, so a custom toolset is only as safe as you make it.
• Added an MCPToolset row to the defense-layers table, which previously omitted it. An MCP server can expose shell, filesystem, or network access, so it warrants an explicit entry: run only trusted servers and audit the tools they expose.

Why

A recurring misconception is that an LLM-driven DAG can "create a connection for itself" and read another connection's credentials. It cannot, unless a registered tool allows it (the existing HookToolset guidance already warns against exposing get_connection). Stating the boundary explicitly heads off that misreading and gives a single standard to audit any custom toolset or MCP server against.