First, to answer your question, I must be clear that no Agile frameworks or methodologies attempt to define everything that a team might need to do (especially Scrum) so there is nothing wrong with adding extra artifacts or practices that the team finds useful as long as they aren't contradicting a defined practice.
There are a few places I typically see non-functional requirements recorded. Here are a few of the most common ones:
Definition of Done
The definition of done contains standards for quality that should be applied across all backlog items that come through. Often times this includes things like "n% unit test coverage of code", "code and configuration changes have been peer reviewed", and "all automated regression tests have been run and pass". I've sometimes seen broader non-functional requirements like "no changes cause the application load time to exceed X ms".
Architectural Design Documents
You can still have these in Agile. Rather than establishing the finished architecture at the beginning of the project, they introduce constraints that the architecture has to stay within. As the project progresses and architectural decisions are made or changed, these documents are updated to reflect that information. Examples of constraints may include "System X is considered to be the authoritative source of customer personal data" or "Details needed for payment processing should never be available to a public-facing server in order to reduce attack opportunities on that data."
Product Chartering
Depending on the project, "starting right away" is a bit fluid. On very large projects or products, it is not uncommon to take a few days (in my experience, 1 - 3 is a good number) to charter the project. This would include identifying personas, making sure business stakeholders and team members have a shared understanding of the vision, talk through some expected user experiences and problems at a high level, etc. It is very common that non-functional needs come out here and should be recorded either in the DoD, existing architectural documents, or in some cases, in backlog items. One good example of this happening is something called a trade-off matrix. When building a tradeoff matrix, we talk about constraints on the project like performance, adaptability, feature set, budget, time, etc. We identify one as a primary constraint, two as secondary, and all others are considered tertiary. This isn't a hard-and-fast rule, but it establishes an general understanding of how trade-offs on non-functional needs will be decided in the work.
Backlog Items
Ok, last one. Not all backlog items have to be User Stories. If you have an actionable non-functional requirement (set up a server, reconfigure a firewall, team needs to convert to a new version of the IDE) there is nothing that stops you from creating a backlog item for this. It isn't a User Story, but that's ok. I will warn that most teams find a correlation between the number of items in the backlog that are User Stories and their ability to effectively deliver value and adapt to changes along the way, so don't get carries away. But I'd rather see a team put in a non-US in their backlog than try to pass off those things as user stories like "As a firewall, I want to be updated, so we don't get h@XX0rD" <- real backlog item I saw.
As a final note: remember that in Agile, we strive to adapt to change, so don't worry about getting the DoD or architectural document perfect the first time. It can change as you learn more.
