Why does security awareness training change behaviour?

Effective training combines knowledge, recognition and practice (phishing simulations). Short monthly modules work better than annual sessions because repetition anchors behaviour.

How do I measure the effectiveness of my awareness programme?

Use phishing click rate as a behavioural measure, track knowledge quiz scores, and monitor the number of suspicious email reports. A drop in click rate over 6 months is a reliable indicator.

How does 2LRN4 support behaviour change?

2LRN4 links risk-based modules (per threat type) to phishing simulations and reporting. Managers see at department level how behaviour develops.

API security awareness for end users

An API is the way applications talk to each other, and in 2026 nearly every modern service does. For end users it sounds abstract, but API security affects their work too: a connected app granted too much access, a personal API key shared in a chat, an AI tool reading your mail. What should you as an employee know, and how do you set this up without a deep technical course?

What is an API, in plain language

An API (Application Programming Interface) is an agreement between two programmes. When you use email on your phone, the mail app talks via an API to the mail server. When you make an online payment, the payment page talks via an API to your bank. When you accept a calendar invite in Microsoft 365, dozens of API calls flow back and forth.

For the user this is invisible, and that is exactly where risks arise. Invisibility means decisions get made that you never consciously made: which app may read your calendar, which AI service may see your documents, which integration sends mail data to a third party.

API security awareness for end users is therefore not about building safe APIs. It is about a few behaviours: know which connections you authorise, treat personal access codes with the same discipline as passwords, and distrust requests asking you to "just share" a key or code.

OAuth consent: the digital signature you give too easily

When an app wants access to your Microsoft 365, Google Workspace or Slack, you get a consent screen: 'This app wants access to: read your email, manage your calendar, share your files.' You tap 'Accept' and the app has access, often for an indefinite period, often with more rights than strictly needed.

In 2026 this is one of the quietest yet most effective attack vectors. An attacker can build a seemingly innocent app (a "calendar helper", an "AI note assistant") and try to lure you into a click. Once accepted the attacker no longer needs your password; consent alone gives them access to your mailbox, and MFA does not help against it.

Rules of thumb: only accept consents for apps you sought out yourself and that are approved by your organisation. Read the rights the app requests, and watch for broad scopes like "read all email" or "manage all files". Periodically review which apps have access to your work account in the Microsoft or Google security centre and revoke what you no longer use.

Personal API keys and tokens: treat them like passwords

Some services give you an API key or access token for a specific purpose: a personal CRM connection, a script pulling data, an integration with a developer tool. That key is technically a password with more rights, and should be treated that way.

Three rules of thumb: never share a key via chat, email or a helpdesk ticket; store it in a password manager or your organisation's dedicated tool; and rotate (renew) it when you suspect it has leaked or when someone with access leaves.

A common mistake is a key ending up in a shared repository (Git, SharePoint), often along with code by accident. Attackers continuously scan public repositories for API keys and try to use them straight away. If you accidentally shared a key, rotate it immediately and report to IT so any malicious action can still be blocked.

AI integrations: a new API risk category

Since 2024 many AI services ask to connect to your mailbox, calendar or files to be "smarter". That is precisely an API authorisation: you give a third party indefinite access to potentially a large body of corporate data.

The rule of thumb aligns with cloud security: only use AI connections approved by your organisation for work. A free AI assistant scanning your mailbox shares your data with a vendor your organisation usually has no contract with. That can be both a GDPR issue and a confidentiality risk.

When in doubt, ask IT which AI connections are approved. Almost every organisation now has a list, and that list is a much better option than accepting a random OAuth screen.

What to do with a suspect API request or suspected leak

Concrete steps when you see something suspicious:

Unsure about an OAuth consent screen? Cancel, screenshot, and ask IT whether the app is legitimate.
Suspect an API key has leaked? Rotate the key immediately via the service and report to IT so they can detect any misuse attempts.
Accidentally shared a key or token in email or chat? Do not just delete the message; first report to IT so they can assess whether it may have left the organisation.
Unexplained integrations on your account? Revoke unknown authorisations immediately via the security centre of your cloud provider, and report to IT.
An email or call asking to "just share a token for maintenance"? Never. Real IT admins have their own access and do not need yours.

How to anchor this in an awareness programme

API security is not a standalone module for every employee, but it belongs somewhere. For general staff a short section in a broader cloud or AI module is enough: what a consent screen is, which rights to refuse, how to report doubt.

For specific groups (developers, IT, marketing, finance) a dedicated module is worthwhile: handling personal keys, recognising dangerous OAuth scopes, dealing with AI connections. Role-based design prevents overload for those who do not need it and gives depth where it counts.

Combine with practical visibility: a list of approved AI connections and apps on the intranet, a fixed reporting point at IT for doubts, and periodic cleanup of OAuth authorisations (once a quarter across the organisation). Make it visible when someone reports a suspect request fast; that normalises the behaviour.

From explanation to action

See how 2LRN4 turns this topic into a workable programme with training, phishing simulation and management reporting.

View the training page

Sources

FAQ

What is an API in plain language?

An agreement letting two programmes talk to each other. Your mail app talks via an API to the mail server; a payment page talks via an API to the bank. To the user this is invisible.

What is OAuth consent?

A screen with which you grant an app rights on your account without sharing your password. A strong mechanism, but one you must use consciously: broad scopes like "read all email" are significant.

Should I treat an API key like a password?

Yes, even more so. An API key often has more rights and is actively hunted by attackers. Store it in a password manager, do not share by chat or email, rotate on doubt.

May I connect an AI service to my work mailbox?

Only if that connection is approved by your organisation. A free AI service reading your mailbox potentially shares confidential data with a third party without a contract. Ask IT for approved alternatives.

What if I accidentally shared an API key?

Rotate it immediately via the service and report to IT. Do not just delete the message; IT must assess whether the key may have left the organisation.

How do I check which apps have access to my work account?

In Microsoft 365 via "My apps" or the security centre; in Google Workspace via "Security" and "Third-party apps with account access". Revoke unknown or unused authorisations.

What does NIS2 say about API security?

NIS2 requires demonstrable measures for risks affecting continuity and information security, including API connections. Awareness of OAuth consent and key handling forms part of the compliance story.