AI Governance for Learning Management Systems: Canvas, Blackboard, Moodle

Three integration architectures, one governance problem

Canvas, Blackboard, and Moodle each expose AI tools and agents through architecturally distinct paths, and none of the three were designed with AI-specific data handling in mind. LTI 1.3, published by 1EdTech, authenticates tool launches using OAuth 2.0 and signed JWTs, replacing the shared-secret model used in LTI 1.1. LTI Advantage extends this with optional services: Names and Role Provisioning Services (NRPS) for roster and PII data, Assignment and Grade Services (AGS) for grade read and write access, and Deep Linking for content embedding. Access under these services depends entirely on the scopes a tool requests and an administrator approves, not on a fixed standard.

Separately, Canvas and Blackboard both offer REST APIs secured by OAuth2 access tokens and developer keys, which can be scoped at account, course, or user level depending on configuration. Moodle and legacy Blackboard Building Blocks take a third approach: native plugins that run inside the application itself, with access to core capabilities and web services that is not constrained by token scoping the way LTI or API access is. An AI tool may use one of these paths or combine several, for example an LTI launch paired with a companion API integration, which produces overlapping permission boundaries that are difficult to reason about from a single administrative console.

Integration architecture comparison

Three LMS connection patterns create the same governance requirement: you need a control layer that does not depend on any single platform’s admin model.

FERPA and the school official exception

FERPA, codified at 34 CFR Part 99, restricts disclosure of personally identifiable information from education records without consent. Most AI tools operating inside an LMS rely on the school official exception, which permits disclosure only when the institution retains direct control over the third party’s use and maintenance of education records and can establish a legitimate educational interest. This obligation is not tied to any particular integration method.

An AI grading assistant accessing student work through an LTI 1.3 launch, a chatbot pulling roster data through NRPS, or a plagiarism detector installed as a Moodle plugin are all subject to the same requirement for institutional control. It is important to note that 1EdTech’s LTI conformance certification verifies protocol behavior only, not a connected tool’s data retention, processing location, or AI-specific handling practices. Certification that a tool implements LTI 1.3 correctly says nothing about whether the vendor’s use of accessed data satisfies FERPA’s direct control requirement, which means institutions cannot treat LTI compliance as a substitute for their own governance review.

Why platform-by-platform policies fragment

Most multi-LMS institutions govern AI tools separately within each system’s native administrative interface, applying LTI scope restrictions in Canvas, developer key rotation in Blackboard, and plugin approval workflows in Moodle. This produces three disconnected policy sets with no shared definition of least privilege and no unified record of what any given AI agent actually did across systems.

The problem compounds when a single AI vendor operates across all three platforms simultaneously, since the same tool may hold NRPS scopes in Canvas, an API token in Blackboard, and installed plugin permissions in Moodle, each configured independently and audited through different logs in different formats. Reconciling three distinct identity and scope models into one consistent least-privilege policy requires a control layer that sits above the LMS-specific configuration, rather than three parallel sets of platform administration.

Runtime controls required across all three architectures

Governing AI behavior consistently across Canvas, Blackboard, and Moodle requires the same four runtime controls applied uniformly regardless of integration path.

• Agent identity

  Establish which AI system or agent is making a given request, distinct from the human user or the LMS credential it operates under, so that an action can be attributed to the tool that performed it.

• Least-privilege permission enforcement

  Limit what an agent can access or execute to what its function actually requires, whether that access is granted through an LTI scope, an API token, or a plugin capability.

• Runtime policy enforcement

  Apply these limits at the point of action rather than relying solely on static configuration set at install time, since AI tools can request or use capabilities dynamically.

• Audit logging

  Capture agent identity and tool-call actions in a consistent format across LTI, API, and plugin channels, producing a single record usable for compliance evidence and incident investigation rather than three incompatible logs.

Trussed AI provides runtime governance for AI agents, including agent identity, least-privilege permission enforcement, and audit logging, applied consistently regardless of the underlying integration architecture an AI tool uses to connect to an LMS.