Skip to content

AI 201 · Module 5

Security, Grounding & Provenance

What makes an AI tool trustworthy: who can call it, what it touches, and what evidence it returns

Start Section 1
0 / 6 completed
Sync my progressJoin a session to keep progress across devices and share it with your instructor

Info

After you join, your completed lesson numbers are sent to your instructor together with your learner code, so they can see your progress. Use the codes your instructor gave you, and do not enter your name, company secrets or other personal data. Progress is kept with the rest of that session's data.

Learning objectives

  • Ask the five security questions of any tool and judge the answers
  • Classify data and rate risk, and match a tool to the right permission level
  • Read a result's provenance fields and decide whether the answer is trustworthy and current
  • Recognize when human confirmation is required, and design errors that fail visibly, not deceptively

Five Questions, Data and Risk

10 min

The Five Security Questions

Connecting AI to tools and data is powerful, and it is also where things go wrong. Before you trust or build any tool, it must be able to answer five questions. If a tool cannot answer them, it is not ready to be used.

  1. Who can call it?
    Anyone, signed-in users, or only specific roles? Enforced on the server, not just hidden in the interface.
  2. What data can it access?
    Public pages, internal records, or personal data? Access should be the minimum the tool needs.
  3. Is it read-only or write-capable?
    A tool that only reads is a very different risk from one that can change, delete, publish or send.
  4. What happens when it fails?
    Does the user get an understandable message, or does the AI quietly fill the gap with a guess?
  5. What evidence accompanies the result?
    Source, timestamps and a link, so a human can check where the answer came from.

Info

Illustrative example: for search_courses, the answers might be "any learner", "public course catalog", "read-only", "a clear unavailable message", and "source plus retrieval time".
Check yourself

Which is one of the five questions every tool must answer?

Which is one of the five questions every tool must answer?

Key takeaway: A trustworthy tool can answer: who calls it, what data, read or write, what on failure, and what evidence.

10 min

Data Classification and Risk Level

Data classification (illustrative examples)
ClassMeaningExample
PublicSafe for anyone to seePublished course catalog
InternalFor members of the organizationInternal meeting schedule
ConfidentialLimited to those who need itUnpublished project budget
RestrictedHighest sensitivity, tightly controlledPersonal records, credentials
Risk level
RiskTypical tool
LowRead-only lookup of public data
MediumRead of internal or restricted data for an authenticated user
HighAnything that writes, deletes, publishes, sends, or changes access

Higher classification and higher risk call for stronger authentication, tighter permissions, more logging and, for high risk, a human confirmation step.

Warning

Never put secrets, tokens, passwords or personal data in prompts, examples or screenshots. Real credentials do not belong in course material or client-side code.
Check yourself

Which tool is best rated High risk?

Which tool is best rated High risk?

Key takeaway: Classify the data, rate the risk, and let both raise the level of protection.

Permissions and Confirmation

10 min

Permission Levels and Human Confirmation

Permission levels
LevelWhat it allowsHuman confirmation
Public ReadAnyone can read public dataNot needed
Authenticated ReadSigned-in users read data meant for themNot needed
Restricted ReadOnly specific roles read sensitive dataDepends on sensitivity
Confirmed WriteChanges data after an explicit human yesRequired
Privileged WriteElevated changes by authorized roles onlyRequired, and logged

The following actions should, in principle, always require explicit confirmation from a human:

  • Writing data
  • Deleting data
  • Publishing content externally
  • Sending a message
  • Changing an account or its permissions
  • Any operation behind a high-impact decision

Warning

Authorization is enforced by the server. A button that is hidden in the interface is not access control, and an AI that "decides" to call a tool is not a human approving it.
Check yourself

An AI assistant proposes deleting a set of records. What should happen?

An AI assistant proposes deleting a set of records. What should happen?

Key takeaway: Write, delete, publish, send and permission changes need authorization plus explicit human confirmation.

Provenance and Failure

10 min

Grounding and Provenance

A grounded answer is based on an authoritative source rather than on the model's guess. Provenance is the evidence trail that lets a human check it. A good result carries fields such as these:

Illustrative tool result with provenance (fictional data)
{
  "results": [
    { "name": "Example Researcher", "expertise": ["AI in education"] }
  ],
  "provenance": {
    "source": "Example University Research Directory",
    "source_id": "expert-0042",
    "retrieved_at": "2026-03-01T09:30:00Z",
    "last_updated": "2026-02-10",
    "canonical_url": "https://example.edu/directory/expert-0042",
    "completeness": "partial (3 of 5 fields available)"
  }
}
  • source and source_id: which system and which record the answer came from
  • retrieved_at: when the tool fetched it
  • last_updated: when the source itself last changed
  • canonical_url: where a human can open the original
  • confidence / completeness: an indicator of how complete the result is, when applicable

Info

The difference between retrieved_at and last_updated matters: fresh retrieval of an old record is still an old record.
Check yourself

A result shows retrieved_at as today but last_updated as two years ago. What does that tell you?

A result shows retrieved_at as today but last_updated as two years ago. What does that tell you?

Key takeaway: Provenance (source, id, timestamps, link, completeness) lets a human verify where an answer came from.

10 min

Fail Visibly, Not Deceptively

Showing only "Error 500" helps nobody. Just as bad is the opposite: a tool fails and the model answers anyway from memory. The principle is: fail visibly, not deceptively.

A well-designed failure message
Unable to retrieve course data.

Reason:
The authoritative course service is temporarily unavailable.

What you can do:
- Try again later
- Check the official course system

No answer was generated from unverified data.
  • Say clearly that the retrieval failed and why, in plain language
  • Give the user next steps they can take
  • Never include secrets or internal details in the message
  • State that no answer was generated from unverified data

Warning

When no trusted data is retrieved, the model must not fill in a guess. An honest "I could not find it" is better than a confident invention.
Check yourself

A course tool returns nothing because the service is down. What is the best behavior?

A course tool returns nothing because the service is down. What is the best behavior?

Key takeaway: Fail visibly, not deceptively: explain the failure and never fill the gap with a guess.

Verification and Responsibility

10 min

Verification Habits and Shared Responsibility

Even a well-built tool does not remove the human from the loop. Build five habits, and use them every time an AI answer relies on a tool.

  1. Check the source
    Is it an authoritative system, and can you open the original?
  2. Check the freshness
    Compare retrieved_at and last_updated with what the question needs.
  3. Check the provenance
    Are source, id and link present, and do they match the claim?
  4. Look for missing information
    Is anything marked partial, or simply absent?
  5. Note the uncertainty
    Separate what the tool returned from what the AI inferred, and say which is which.
Human, AI, Tool, Human
  1. Human defines the intent and the boundaries
  2. AI selects a capability and prepares the call
  3. The tool invokes trusted data or performs an action within its permissions
  4. Human verifies the result and remains responsible for using it

Done

Using a tool does not transfer responsibility. Learn teaches these habits; the NTPU AI4X MCP runs the tools and its own documentation covers setup.
Check yourself

Who is responsible for an answer that an AI built from a tool result?

Who is responsible for an answer that an AI built from a tool result?

Key takeaway: Check source, freshness, provenance, gaps and uncertainty; the human stays responsible.

What next?