AI can write an Application Service in seconds. But who gave it permission to run?
That’s the question developers need to ask when reviewing AI-generated code in ASP.NET Zero.
Tools such as GitHub Copilot and other AI coding assistants can generate an Application Service, add authorization attributes, create permission constants, and even suggest the corresponding UI changes. Last week we covered running AI actions as Hangfire jobs. The week before that was using Copilot without inventing login. This week is the grant that sits on the method: the permission.
The code may compile.
The endpoint may work.
The feature may look perfect.
But one overly broad permission can give users access to an operation they were never supposed to perform.
In an ASP.NET Zero application, permissions are not just another line in the code. They define who can access features and operations.
So when AI adds a permission, review the permission before reviewing the rest of the method.
ASP.NET Zero provides user, role, and permission-based authorization as part of its application architecture. Permissions determine whether a user can access particular features or operations.
A typical ASP.NET Zero application might have permissions such as:
Pages_Administration_Books
Pages_Administration_Books_Create
Pages_Administration_Books_Edit
Pages_Administration_Books_Delete
The important part isn’t the naming convention.
It’s the relationship between:
User → Role → Permission → Application Service → Operation
An AI assistant can generate that chain.
It cannot know whether the permission is actually appropriate for your business.
That’s why authorization needs a human review.
When reviewing an AI-generated Application Service, don’t start by reading every line of business logic.
Start with the authorization.
Ask:
Who can call this method?
Which permission grants access?
Is that permission already defined?
Is it a tenant permission or a host permission?
Does the permission give users more access than the feature requires?
For example:
[AbpAuthorize(AppPermissions.Pages_Orders)]
public async Task ApproveOrderAsync(int orderId)
{
// AI-generated business logic
}
The method may look completely reasonable.
But what does Pages_Orders actually allow?
If that permission was intended only for viewing orders, using it for an approval operation may have silently widened access.
The method works.
The authorization design doesn’t.
One common AI-generated pattern looks something like this:
[AbpAuthorize("Pages.Orders.AiApprove")]
It looks legitimate.
But if that permission isn’t defined in the application’s authorization system, the implementation isn’t complete.
In newer ABP Framework applications, permissions are typically defined through PermissionDefinitionProvider, where permissions can also be organized into groups and child permissions.
Older ASP.NET Zero applications commonly use centralized permission constants such as AppPermissions.
The version of the application matters.
That’s why an AI-generated permission name should never be accepted simply because it looks consistent with the rest of the code.
Search for the definition.
If you can’t find it, stop the review there.
This is where human judgment matters most.
Suppose your application already has:
Orders
Orders.Create
Orders.Edit
Orders.Delete
And AI creates:
Orders.AiApprove
Should you keep it?
Not automatically.
Ask what the new operation actually represents.
If AI is simply performing the same approval operation that an existing authorized user can already perform, an existing permission may be appropriate.
If AI introduces a genuinely different capability, a separate permission may make sense.
The goal isn’t to create as many permissions as possible.
The goal is to create permissions that accurately represent the actions your application allows.
A permission isn’t finished just because the attribute compiles.
For a new permission, verify the complete path:
Definition → Localization → Role Management → Grant → Application Service
ABP Framework’s permission system supports defining permissions, displaying them in the permission management UI, and granting or prohibiting them for roles and users. It also supports defining whether a permission belongs to the host side, tenant side, or both.
That means your review should include the UI as well as the code.
Ask:
If the answer to these questions is no, the permission implementation isn’t complete.
This becomes especially important in ASP.NET Zero multi-tenant applications.
A permission intended for a host administrator should not automatically become available to tenant users.
Likewise, a tenant-level Application Service should not accidentally depend on a host-only permission. We made a related point for generated CRUD in How to Use ASP.NET Zero Power Tools Without Breaking Multi-Tenancy: pretty code is not the test. Tenant B still has to fail.
ABP Framework explicitly supports assigning permissions to the Host, Tenant, or Both sides.
So when AI creates a new permission, check its tenancy scope.
A simple question helps:
Who is supposed to perform this action?
Host administrator?
Tenant administrator?
Regular tenant user?
System process?
The answer should determine where the permission belongs.
The easiest mistake to miss is a permission that is technically valid but too powerful.
Imagine an AI assistant creates:
[AbpAuthorize(AppPermissions.Pages_Users)]
public async Task ResetAllUserPasswordsAsync()
{
...
}
The permission exists.
The code compiles.
The role management screen shows it.
But the permission may still be far too broad for the operation.
This is why authorization review isn’t simply:
“Does the permission exist?”
It’s also:
“Does this permission grant exactly the access this operation requires?”
The principle applies to both AI-generated code and manually written code.
Another common mistake is assuming that hiding a button protects the operation.
It doesn’t.
You might hide an Approve button from a user in Angular.
That doesn’t mean the underlying Application Service is protected.
The API or Application Service remains the actual enforcement point.
ABP supports authorization on Application Services, while ASP.NET Core provides the underlying authorization infrastructure.
Think of it this way:
The UI decides what the user sees.
Authorization decides what the user can actually do.
AI-generated code needs to respect both. The same rule applies when AI tools call your services from a background job: keep the grant on the Application Service, not only on the Angular template. See Building AI-Native Features in ASP.NET Zero.
Before merging an AI-generated Application Service, run this checklist:
Find its definition.
Don’t accept a permission simply because its name sounds correct.
Check the application’s multi-tenancy rules.
Make sure administrators can grant and revoke it.
Don’t leave raw permission keys exposed in the UI.
Check whether the permission grants more access than the operation needs.
Test the actual endpoint, not just the UI.
If any answer is unclear, the AI-generated code isn’t ready to merge.
[AbpAuthorize]?If you’re working with an older ASP.NET Zero codebase, you may see [AbpAuthorize] throughout the application.
For newer ABP Framework applications, the recommended approach is the standard ASP.NET Core [Authorize] attribute together with ABP’s permission system. ABP’s migration guidance specifically distinguishes the older ASP.NET Boilerplate/ASP.NET Zero authorization patterns from the newer ABP Framework approach.
So don’t blindly replace or add authorization attributes based on what an AI assistant suggests.
First identify the authorization pattern your application actually uses.
Then make the AI-generated code follow that pattern.
This is probably the most important distinction.
AI is useful for:
But the final decision about who should be allowed to perform an operation belongs to the application team.
The permission is part of your security boundary.
It deserves the same review as database access, tenant isolation, and authentication.
Find the definition, confirm host vs tenant, check the role screen, then prove an unauthorized role cannot call the method.
No. A string in [AbpAuthorize] is not a definition, a localization entry, or a grant. Search for all three.
Only if the operation is actually new. Reuse the existing grant when the AI path does the same work a human already does under that permission.
No. UI visibility is not authorization. Test the Application Service as a user who should be denied.
Not always. Someone who has been burned by ABP grants, plus your people who know the domain, beats a merge that treats Copilot as a security reviewer.
AI-generated code makes development faster.
That makes code review more important, not less.
When an AI assistant creates an ASP.NET Zero Application Service, don’t start by asking whether the method works.
Start with:
Who can call it?
Which permission allows it?
Where is that permission defined?
Which roles receive it?
Is it host or tenant scoped?
Does it grant more access than the feature requires?
A feature that returns the right result to the wrong user is still broken.
Read the permission before you admire the code.
AI-assisted development can accelerate ASP.NET Zero development, but permissions, multi-tenancy, authorization, and application architecture still require careful engineering review.
If your team is building or modernizing an ASP.NET Zero application and needs experienced ASP.NET Zero developers, our dedicated development team can help with application development, AI integration, authorization, and ongoing modernization. Get in touch, or start with Development from Zero.
Sources: ABP, Authorization accessed 2026-09-28; ASP.NET Zero, Authorization for Phone Book accessed 2026-09-28.
Get In Touch
Hire ASP.Net Zero Application Developers that will provide the perfect solution to your business issues. Our technical experts will provide you with a free consultation.
AI can generate an answer in seconds. Your HTTP request should not wait for it. Queue the work as an ASP.NET Zero background job, run it with Hangfire, keep tenant context, and notify Angular over SignalR.
Read more →
How to use Copilot on ASP.NET Zero without inventing login: v15.2 AI skills, tenant filters, and a Tenant B smoke test. Fast code still has to pass your permissions.
Read more →
How to use ASP.NET Zero Power Tools without leaking tenants: what the generator creates, IMustHaveTenant, ABP data filters, and a Tenant B smoke test.
Read more →