Two Checkboxes I'm Glad I Found in January

Any account could generate a key to every student's grades. Here's the afternoon I closed that door.

On a Monday morning back in January I scrolled through the account settings menu in Canvas. Sometimes Instructure implements things into Canvas that I didn’t see coming in their Release Update or Deploy Update webpages. I noticed two new items with checkboxes, unchecked by default. “Limit personal access token creation to Admins.” And “Restrict students and observers from creating personal access tokens.”

I read them again, thought about it for a minute, then checked both. Seemed like a good way to learn who might be creating access tokens in my Canvas instance.

Every Canvas admin knows personal access tokens open a door to a room full of student information. What’s easy to forget is what kind of key you’re handing over. A personal access token carries the full read and write permissions of the account that created it, and it answers to none of the protections we count on everywhere else. It slips past Single Sign-On and multi-factor authentication, ignores session timeouts, and never sees a login page. Once it exists, it just works, quietly, until someone remembers it’s there and shuts it off. And it leaves no footprint in the places most of us admin normally look.

Up until I checked those boxes to disable creation, any account at my institution could create one. Any faculty member, any TA, any student, any observer.

Then the emails started

For a week, nothing happened. Then the requests started trickling in. A faculty member would go to generate a token, find they couldn’t, and email me to ask why. Fewer than ten of these, all told, over the following months.

I braced for annoyance, but got something better. Every one of those emails I received was a small, but important, bit of information.

Each person who wrote in was telling me something I wasn’t aware of. They were running their own integration against my LMS. A number were using tokens for grading, real API calls against real student data, automations they’d built themselves and had been quietly running for who knows how long. None of it was malicious, but all of it was invisible to me until my box-checking brought it into the open.

What I do now instead of just saying no

The access token lockdown isn’t an automatic no, it’s a checkpoint. When someone has a legitimate need, I still issue a token. I just issue it deliberately, with terms, instead of letting the system hand out keys to anyone who clicked on the button.

Before I generate a token now, the requester replies to an email agreeing to a short set of responsibilities. They agree to store the token securely and use it only for the current term’s courses. They agree not to hardcode it into a public repo, not to share it, and not to use it to mass-extract student data. They acknowledge FERPA and our state’s data-protection and AI guidelines if the token ever touches a third-party tool. And they accept that every action the token takes is logged under their name in the audit trail, which makes them accountable for what their scripts do.

Then the token I issue expires in six months. If their use case outlives the token, we have the conversation again, which means the integration gets re-examined on a schedule instead of running forever. One email exchange converts a silent, permanent, invisible grant into a documented, expiring, accountable one. And the agreement itself becomes the record. Every token I’ve issued since January has a reply sitting in my inbox where the person accepted the terms in their own words, which means my documentation trail is solid. If anyone ever asks who authorized what, I do a quick search in my email for “access token” and I get the list of requestors.

The uncomfortable part

A forgotten token, sitting in a config file or a notebook or an old script on a laptop that left with an employee, is exactly the kind of thing that turns into an incident nobody can explain later. Now that there is an expiration date on a possibly-forgotten token, it’s one less email thread in the future I would be added to explain why data was compromised.

I got lucky that a quiet Monday morning and two checkboxes lined up for me in January. But it shouldn’t take luck. If your Canvas instance still lets any account generate personal access tokens, it’s 15 minutes of your week worth spending to consider the impact of checking two boxes already sitting in your admin settings menu.

The keys were being handed out the whole time. I just decided to be the one holding them.